WP6-09: Difference between revisions
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Gazebo DronePort Extensions = | = Gazebo DronePort Extensions = | ||
= | {|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 | 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 | [[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 | 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
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.
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.
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.