WP6-09: Difference between revisions

From COMP4DRONES
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Gazebo DronePort Extensions =
= Gazebo DronePort Extensions =


== WORK IN PROGRESS ==
{|class="wikitable"
|  ID|| WP6-UWB
|-
|  Contributor || UWB
|-
|  Levels || Tool
|-
|  License || Open-source
|}


Gazebo DronePort Extensions (GDE) is a set of tools that enables 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 agent can be either a drone or the DronePort device. It consists of several parts necessary to run the simulation. In particular it is DronePort model for Gazebo, 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
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]]
[[File:Droneport_scheme.png|500px|center|Gazebo DronePort Extensions simulation scheme]]
Line 9: Line 19:
== Description ==
== 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 steps, 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 battery exchange as is the case of a real device. The model is shown in Figure 2.
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 dron.]]
[[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 MAVLink protocol to other simulation parts.
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.  
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.  
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 own refueling 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.  
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 ==
== Interoperability with other C4D tools ==


GDE can be extended by Paparazzi UAV autopilot to simulate other than PX4 autopilot which is currently used. Moreover, precision landing developer by Sherpa can be used with GDE in simulation environment.
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]]
[[File:Droneport_interoperability_graph.png|500px|center|Gazebo DronePort Extensions simulation scheme]]

Latest revision as of 11:46, 12 October 2022

Gazebo DronePort Extensions

ID WP6-UWB
Contributor UWB
Levels Tool
License Open-source

Part of the 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

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.

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.

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.