COMP4DRONES - User contributions [en]

WP3-26

2022-10-14T12:25:21Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

{|style="margin: 0 auto;"
|[[File:Droneport overview.jpeg|300px|thumb|upright|Droneport overview]]
|[[File:Droneport gripper.jpg|300px|thumb|upright|Detail of the gripper]]
|[[File:Droneport_320_240.gif|300px|thumb|upright|Droneport battery exchange]]
|}

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport schema IO.png|400px|thumb|right|Droneport internal components and communication buses]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:24:37Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport schema IO.png|400px|thumb|right|Droneport internal components and communication buses]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:24:15Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport schema IO.png|400px|thumb|right|Droneport internal components and communication buses]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.
{|style="margin: 0 auto;"
|[[File:Droneport overview.jpeg|300px|thumb|upright|Droneport overview]]
|[[File:Droneport gripper.jpg|300px|thumb|upright|Detail of the gripper]]
|}

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:23:48Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
{|style="margin: 0 auto;"
|[[File:Droneport overview.jpeg|300px|thumb|upright|Droneport overview]]
|[[File:Droneport gripper.jpg|300px|thumb|upright|Detail of the gripper]]
|}
[[File:Droneport schema IO.png|400px|thumb|right|Droneport internal components and communication buses]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:23:17Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
{|style="margin: 0 auto;"
|[[File:Droneport schema IO.png|400px|thumb|upright|Droneport internal components and communication buses]]
|[[File:Droneport overview.jpeg|300px|thumb|upright|Droneport overview]]
|[[File:Droneport gripper.jpg|300px|thumb|upright|Detail of the gripper]]
|}

The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:20:37Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport schema IO.png|600px|thumb|right|Droneport internal components and communication buses]]
[[File:Droneport overview.jpeg|300px|thumb|center|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|center|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:20:14Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|center|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|center|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.
[[File:Droneport schema IO.png|600px|thumb|right|Droneport internal components and communication buses]]

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T12:19:36Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|center|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|center|Detail of the gripper]]
[[File:Droneport schema IO.png|200px|thumb|center|Droneport internal components and communication buses]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

File:Droneport schema IO.png

2022-10-14T12:17:59Z

Uwb:

WP3-26

2022-10-14T09:10:57Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol with other devices in the network. The device is controlled using Linux based PC with REXYGEN as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T09:10:29Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. DP is a unique device that is able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the UAVs
* The whole device communicates wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-14T09:06:14Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-13T08:16:28Z

Uwb: /* Software Repository */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

*[https://github.com/UWB-C4D Droneport project]
*[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
*[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-13T08:16:02Z

Uwb: software repo added

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

=Software Repository=

[https://github.com/UWB-C4D Droneport project]
[https://github.com/UWB-C4D/droneport_traffic_control Droneport Traffic Control]
[https://github.com/UWB-C4D/droneport_gazebo_extensions Gazebo Droneport Extensions]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-13T08:10:42Z

Uwb: /* Droneport Trajectory Planning */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planning.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-12T13:17:10Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=
[[File:Droneport overview.jpeg|300px|thumb|right|Droneport overview]]
[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-12T13:15:58Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]
The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-12T13:15:41Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

[[File:Droneport gripper.jpg|300px|thumb|right|Detail of the gripper]]

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-12T13:15:23Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

[[File:Droneport gripper.jpg|200px|thumb|left|Detail of the gripper]]

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-12T13:14:39Z

Uwb: /* References */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

[[File:Droneport gripper.jpg|300px|frame| Detail of the gripper]]

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38). [https://doi.org/10.1145/3522784.3522800 DOI:10.1145/3522784.3522800]

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham. [https://doi.org/10.1007/978-3-030-87725-5_2 DOI:10.1007/978-3-030-87725-5_2]

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE. [http://dx.doi.org/10.1109/MMAR55195.2022.9874309 DOI:10.1109/MMAR55195.2022.9874309]

WP3-26

2022-10-12T13:14:29Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

[[File:Droneport gripper.jpg|300px|frame| Detail of the gripper]]

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T13:14:03Z

Uwb: /* Design and Implementation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

[[File:Droneport gripper.jpg|frame| Detail of the gripper]]
[[File:Droneport gripper.jpg|frame| Detail of the gripper]]

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T13:09:41Z

Uwb: /* Droneport Commander */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
[[File:Droneport-drone-state-diag.png|thumb|250px|Simplified chart of drone states]]

In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored.

[[File:Droneport-monitoring.jpg|thumb|350px|Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Map with simulated devices]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation includes QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T13:07:20Z

Uwb: /* Droneport Commander */ images

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in [[:File:Droneport-drone-state-diag.png|Figure 59]].

[[File:Droneport-drone-state-diag.png|thumb|250px|Fig. 59: Simplified chart of drone states]]

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in [[:File:Droneport-monitoring.jpg|Fig. 60]] which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In [[:File:Droneport-qgc-mission.png|Fig. 61]], you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

[[File:Droneport-monitoring.jpg|thumb|350px|Fig. 60: Simulation]]
[[File:Droneport-qgc-mission.png|thumb|350px|Fig. 61: Map with simulated devices]]

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

File:Droneport gripper.jpg

2022-10-12T13:00:46Z

Uwb:

File:Droneport overview.jpeg

2022-10-12T12:56:36Z

Uwb:

WP3-26

2022-10-12T12:54:44Z

Uwb: /* Simulation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository [[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:54:31Z

Uwb: /* Simulation */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
At first, the Droneport can be used in the simulation environment. The software in the loop (SIL) simulation is suitable for designing various traffic scenarios, checking the necessary number of landing platforms, etc. More information about the simulation tools can be found in the tool repository[[WP6-09]]

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:49:43Z

Uwb:

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

= References =

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:49:16Z

Uwb: /* WIP */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=Videos=

You can see the video of the Droneport here:

[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]

[https://youtu.be/juaGfW2ODYQ Droneport in action]

WP3-26

2022-10-12T12:48:05Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|right|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:47:46Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|frame|left|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely, battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for an automatic battery exchange, a data link to the drone, telemetry data, and a human-machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging, provides necessary navigation information for drone landing, and broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:46:45Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.
[[File:Droneport_320_240.gif|640px|frame|left|Droneport battery exchange]]

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

File:Droneport-qgc-mission.png

2022-10-12T12:45:25Z

Uwb:

WP3-26

2022-10-12T12:43:46Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
[[File:Droneport_320_240.gif|640px|thumb|left|Droneport battery exchange]]
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:43:24Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

[[File:Droneport_320_240.gif|640px|thumb|left|Droneport battery exchange]]

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

File:Droneport-monitoring.jpg

2022-10-12T12:43:20Z

Uwb:

File:Droneport-drone-state-diag.png

2022-10-12T12:43:06Z

Uwb:

WP3-26

2022-10-12T12:42:44Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

[[File:Droneport_320_240.gif|640px|thumb|center|Droneport battery exchange]]]

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:38:06Z

Uwb: /* Description */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

[[File:Droneport_320_240.gif]]

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:37:54Z

Uwb: /* WIP */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:36:18Z

Uwb: /* WIP */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[https://www.youtube.com/watch?v=X_33DVXDpGE Droneport basic principle ]
[https://youtu.be/juaGfW2ODYQ Droneport in action]

see tools repository
[[File:Droneport_320_240.gif]]

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:35:51Z

Uwb: /* WIP */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=

You can see the video of
[Droneport basic principle https://www.youtube.com/watch?v=X_33DVXDpGE]
[Droneport in action https://youtu.be/juaGfW2ODYQ]

see tools repository
[[File:Droneport_320_240.gif]]

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:22:34Z

Uwb: /* WIP */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=
see tools repository
[[File:Droneport_320_240.gif]]

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:21:42Z

Uwb: /* WIP */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=
see tools repository
[[Droneport_320_240.gif]]

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

File:Droneport 320 240.gif

2022-10-12T12:20:44Z

Uwb:

WP3-26

2022-10-12T12:14:11Z

Uwb: /* Droneport: an autonomous drone battery management system */

=Droneport: An autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=
see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T12:13:47Z

Uwb:

=Droneport: an autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=Droneport Traffic Control=

The Droneport Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the Droneport it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple Droneports and redistribute the battery replacement requests between available Droneports.

DPTC component currently includes three subcomponents. The first subcomponent is the Droneport Commander, which communicates with drones and Droneports. Droneport Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the Droneport, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to Droneport to change the drone's battery. The second subcomponent is the Droneport Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the Droneport Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning Droneport occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==Droneport Commander==
In the current version, Droneport Commander monitors the status of the drones and withdraws them to the Droneport as needed when the battery State of Charge (SoC) is low. Droneport Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own Droneport. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, Droneports, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==Droneport Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/trajectory_planner.ipynb Droneport Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the Droneport system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the Droneport coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==Droneport Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/Droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=
see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). Droneport: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP6-09

2022-10-12T11:46:43Z

Uwb:

= Gazebo DronePort Extensions =

{|class="wikitable"
| ID|| WP6-UWB
|-
| Contributor || UWB
|-
| Levels || Tool
|-
| License || Open-source
|}

Part of the [[WP3-26|Droneport: an autonomous drone battery management system]]

Gazebo DronePort Extensions (GDE) is a set of tools that enables the Gazebo simulator to simulate [1] an autonomous battery management system called Droneport [2],[3]. It is proposed and developed by the team from New Technologies for Information Society research centre at the University of West Bohemia. Using GDE, it is possible to simulate all functionalities of the DronePort device in single or multi-agent scenarios, where an agent can be either a drone or the DronePort device. It consists of several parts necessary to run the simulation. In particular, it is the DronePort model for Gazebo, the DronePort plugin for Gazebo, a set of Models used for simulation based on the PX4_SITL_Gazebo repository. Finally, scripts for running the simulation and for testing DronePort capabilities are also part of the GDE. All parts are shown in Figure 1

[[File:Droneport_scheme.png|500px|center|Gazebo DronePort Extensions simulation scheme]]

== Description ==

The DronePort model is a box-shaped device with an openable cover containing ArUco code on its top. The model was significantly improved compared to the previous version, modelled as a static, rigid box with ArUco code. The DronePort system has an overview of the battery status of individual drones. Thus, it can prepare for the battery change by doing the following steps. In the first step, it withdraws the drone from the mission. Then the cover of the device opens in reaction to a MAVlink message. When the drone has successfully landed, the device changes its battery. Then, the drone can take off, and a removed battery is put into one of the charging stations in the device. In the simulation, there is a simplification. The changing process is instantaneously done by virtual swapping batteries in the memory. In other words, the simulation doesn’t incorporate the arm for a battery exchange, as is the case of a real device. The model is shown in Figure 2.

[[File:Droneport_v_2_open.png|500px|center|DronePort model with the landed Iris drone.]]

The proposed toolchain is based on three prerequisites. The first one is the Gazebo simulator, for which whole simulation extensions are developed. The second one is the PX4 open-source autopilot, and the third one is the Gazebo software in the loop components called the PX4-SITL_Gazebo plugin suite. In particular, the DronePort plugin is based on the mavlink_interface plugin and GPS plugin. The first one enables DronePort to communicate through the MAVlink protocol. The other one is used to enable DronePort to emulate and broadcast its GPS coordinates through the MAVLink protocol to other simulation parts.

The simulation using our toolchain can be based either on Gazebo only or on Gazebo with Robot operating system (ROS) support. Both options are possible thanks to the use of the MAVLink communication protocol. Therefore, in the first case, the developer can communicate with DronePort using an arbitrary MAVLink communication protocol library. As an example, a python library called pymavlink can be mentioned. Examples of cover movement and battery status messages are implemented using this library.
It was mentioned that the second case is to use the ROS framework to communicate with the simulation of the DronePort device. MAVROS library is needed as it is a ROS implementation of the MAVLink communication protocol.

The simulation should be connected to DronePort control software which is, in our case, implemented in RexyGen software. But it can be implemented in arbitrary technology, again with the only condition of using the MAVLink communication protocol. The control software also sends information about the battery refuelling process. Thus, the Gazebo plugin is used only to visualize the battery refuelling process. It is advantageous because the developer can implement its refuelling process. In more detail, it can have different types of refuelling curves – e.g., linear, quadratic, etc. The interoperability graph is shown in Figure 4.

== Interoperability with other C4D tools ==

GDE can be extended by Paparazzi UAV autopilot to simulate other than PX4 autopilot which is currently used. Moreover, the precision landing developer by Sherpa can be used with GDE in the simulation environment.

[[File:Droneport_interoperability_graph.png|500px|center|Gazebo DronePort Extensions simulation scheme]]

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). DronePort: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.

WP3-26

2022-10-12T11:46:08Z

Uwb: /* Detailed Description */

=Droneport: an autonomous drone battery management system=
{|class="wikitable"
| ID|| WP3-26
|-
| Contributor || UWB and SM
|-
| Levels || Functional
|-
| Require || Communication service to obtain data from the assigned drones and master controller
|-
| Provide || Autonomous battery exchange and management for UAV
|-
| Input
|
* MAVLink-based request for battery exchange
* UAV mission
* UAV battery status
|-
| Output || Available battery resources
|-
| C4D building block || Health management, Mission management
|-
| TRL || 4
|}

=Description=
Droneport (DP) is a system for autonomous drone battery management. It complies with a reference architecture, dealing with drone power management, more precisely battery management. Regarding the reference architecture, the DP consists of a battery management unit for charging and storage, a robotic manipulator for automatic battery exchange, a data link to the drone, a telemetry data and human machine interface (HMI) for remote command and control. Power and storage management building blocks are implemented in Droneport, with a datalink connection to the outside world. Users can use telemetry data via MAVLink protocol to monitor the state of the DP. The DP acts autonomously, it monitors the state of the batteries, controls the battery exchange and charging providing necessary navigation information for drone landing, broadcasts the status of the remaining batteries.

=Contribution and Improvement=

The Droneport aims to extend the UAV missions by autonomously changing the battery of the drones.

The main goal was to develop a drone Battery management architecture fulfilling a few fundamental objectives:
* battery charging and swapping automatically
* extending the UAV operational time from minutes to hours or more
* MAVLink based data communication standards
* compact and easy handling
* reasonable purchasing/maintenance costs

The DP behaves as a standalone autonomous unit that is wirelessly interconnected with one or more UAVs. It is compatible with other C4D components. It uses an open MAVLink protocol with defined messages for communication and commands. The DP was developed as a part of Comp4Drones project from the scratch up to the technology readiness level 4 (TRL4). At the beginning of the project, there was only a notion of how to extend the operational time of UAV missions.

=Design and Implementation=

Figure 85: Droneport manipulator arm with a custom gripper

The Droneport development is done together with SmartMotion company. Our team collaborates together on hardware and software design. The DP will be a unique device that will be able to communicate with various UAVs. For better support of battery exchange, the DP contains a newly designed gripper and a special battery holder. Droneport hardware consists of:

* Drone landing place with ArUco based landing markers
* Uniquely designed robotic manipulator
* Uniquely designed gripper
* Battery management unit for charging and storage
* Wireless communication to the drone/swarms
* The whole device will communicate wirelessly over MAVLink protocol [29] with other devices in the network. The device is controlled using Linux based PC with REXYGEN [34] as real-time control software.

Droneport SW architecture consists of:

* Drone to DP communication protocol (defined MAVLink messages)
* Drone landing assistant - vision navigation to ArUco markers
* Battery exchange system control - manipulator controller
* Charge control - communication interface between charges and battery slots
* Battery management software
* DP software provides an open API for interoperability with various drones flight controllers.

Figure 86: Top view of the Droneport with landed drone

=DronePort Traffic Control=

The DronePort Traffic Control (DPTC) component provides a whole system for multiple drone battery management. It provides means for the orchestration of the drone fleets. Based on the monitoring and prediction of the drone battery states and the states of the batteries provided by the DronePort it plans the interruption and resumption of the drone missions. It also makes it possible to coordinate multiple DronePorts and redistribute the battery replacement requests between available DronePorts.

DPTC component currently includes three subcomponents. The first subcomponent is the DronePort Commander, which communicates with drones and DronePorts. DronePort Commander receives the drone status (location, mission and mission progress information, speed, and battery information). It commands the drones to fly to the DronePort, initiates the battery swapping, and ensures a smooth mission follow-up. It sends commands to DronePort to change the drone's battery. The second subcomponent is the DronePort Trajectory Planner which plans the collision-free trajectory of the drone concerning battery discharge. The last subcomponent is the DronePort Orchestrator, which takes care of optimal scheduling of drone battery replacement concerning DronePort occupancy with minimum mission cost (in terms of distance, fuel, etc.).

==DronePort Commander==
In the current version, DronePort Commander monitors the status of the drones and withdraws them to the DronePort as needed when the battery State of Charge (SoC) is low. DronePort Commander was tested in a simulated scenario with two drones, where each drone is assigned to its own DronePort. Two different missions were designed for testing in the simulation, in which the park and adjacent buildings are monitored. A simplified state diagram of the drone is shown in Figure 59.

DP Commander is implemented in Python and utilizes the [https://github.com/ArduPilot/pymavlink pymavlink] library to communicate with drones and the platform. A simple console user interface was designed using the [http://urwid.org/ Urwid] library. The monitoring of the whole simulation is depicted in Figure 60 which shows QGroundControl (QGC) as a standard control center (the client-side), the simulation of the physical devices in Gazebo, and the previously mentioned DPTC interface. In Figure 61, you can see the two drones, DronePorts, the area under consideration, the specified missions, and other standard information provided by QGC. The console user interface contains information and commands for both drones, and it is easily adaptable for more drones.

==DronePort Trajectory Planning==
As part of the study for the [https://github.com/UWB-C4D/droneport_traffic_control/blob/main/trajectory_planner.ipynb DronePort Trajectory Planning] subsystem, a non-collisional drone trajectory that is optimal in terms of battery State of Charge (SoC) was found for the demonstration. The trajectory planning problem was described as an Optimal Control Problem using the Chebyshev pseudospectral method.

For the DronePort system, it has not been necessary to consider collision avoidance yet, hence this part remains purely experimental. In the current state, the drone is sent directly to the DronePort coordinates. Possible collision avoidance can be performed by control systems at the drone level.

==DronePort Orchestrator==
Droneport Traffic Control has no ambition to organize the customer's flight missions themselves, but to provide services to maximize the flight time of drones. We consider static Droneports, the drone mission is given by the customer. The DPTC interrupts the mission at a convenient moment so that the drone battery is recharged, and the mission can continue.

In the scheduling of battery exchange the appropriate time to withdraw the drone is sought with the well-known A* algorithm ([https://github.com/UWB-C4D/droneport_traffic_control/blob/main/simple_orchestrator.ipynb see example]). According to predicted SoC and evaluated costs for flight to Droneport platforms, the optimal schedule is sought, which is composed of Drone ID, Droneport ID, and mission sequence ID.
The prediction of discharge rate is acquired based on distances between mission waypoints, the drone’s velocity, maximum flight time, and initial SoC. The cost of battery replacement is determined by the predicted drone battery drain during its flight to the Droneport platform and back to the mission. The task is further limited by a fixed number of charged batteries in the Droneport platforms. The Orchestrator also performs a calculation of the expected flight time to the Droneport platform, based on which a time slot is entered into the schedule with a safe time reserve to avoid drone collisions near the DP platform.
The Droneport Orchestrator passes the found solution to the Droneport Commander. The solution is found periodically by running the problem with updated data. Droneport Commander monitors the progress of the missions, sends commands to the drones according to the plan, and verifies that battery replacements are performed at specified intervals.

=Simulation=
see tools repository

=WIP=
see tools repository

== References ==

'''[1]''' Severa, O., Bouček, Z., Neduchal, P., Bláha, L., Myslivec, T., & Flidr, M. (2022). Droneport: From Concept To Simulation. In System Engineering for constrained embedded systems (pp. 33-38).

'''[2]''' Bouček, Z., Neduchal, P., & Flídr, M. (2021, September). DronePort: Smart Drone Battery Management System. In International Conference on Interactive Collaborative Robotics (pp. 14-26). Springer, Cham.

'''[3]''' Bláha, L., Severa, O., Barták, P., Myslivec, T., Jáger, A., & Reitinger, J. (2022, August). Droneport: From Concept To Prototype. In 2022 26th International Conference on Methods and Models in Automation and Robotics (MMAR) (pp. 134-139). IEEE.