mirror of
https://github.com/CopterExpress/clover.git
synced 2026-06-04 16:59:31 +00:00
Merge branch 'master' into 22-armhf
This commit is contained in:
Oleg Kalachev
@@ -1,4 +1,4 @@
|
||||
<!-- markdownlint-disable MD041 -->
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/"><img src="../assets/cc-by-nc-sa.svg"></a>
|
||||
This documentation is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License</a>.
|
||||
This documentation is licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/4.0/">Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License</a>.
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# COEX Clover
|
||||
|
||||
<img class="center bigclever zoom" src="../assets/clever4-front-white-large.png" width="80%" alt="COEX Clover 4">
|
||||
<img class="center zoom big-clover" src="../assets/clover42-main.png" width="80%" alt="Clover 4.2">
|
||||
|
||||
**Clover** is an educational kit of a programmable quadcopter that consists of popular open source components, and a set of necessary documentation and libraries for working with it.
|
||||
|
||||
The kit includes a Pixhawk/Pixracer flight controller with the PX4 flight stack, a [Raspberry Pi 4](raspberry.md) as a controlling onboard computer, and a [camera module](camera.md) for performing flights with the use of computer vision, as well as a set of various sensors and other peripherals.
|
||||
The kit includes a [COEX Pix](coex_pix.md) flight controller with the PX4 flight stack, a [Raspberry Pi 4](raspberry.md) as a controlling onboard computer, and a [camera module](camera.md) for performing flights with the use of computer vision, as well as a set of various sensors and other peripherals.
|
||||
|
||||
The Clover platform contains a [pre-configured image for Raspberry Pi](image.md) with the full set of required software for working with peripheral devices and [programming autonomous flights](simple_offboard.md). The source code of the platform and of the documentation is open and [available on GitHub](https://github.com/CopterExpress/clover).
|
||||
|
||||
|
||||
@@ -54,13 +54,17 @@
|
||||
* [MAVROS](mavros.md)
|
||||
* [Supplementary materials](supplementary.md)
|
||||
* [COEX Pix](coex_pix.md)
|
||||
* [COEX PDB](coex_pdb.md)
|
||||
* [COEX GPS](coex_gps.md)
|
||||
* [Guide on autonomous flight](auto_setup.md)
|
||||
* [Hostname](hostname.md)
|
||||
* [PX4 Simulation](sitl.md)
|
||||
* [Navigation using vertical ArUco-markers](wall_aruco.md)
|
||||
* [PID Setup](calibratePID.md)
|
||||
* [Model files for parts](models.md)
|
||||
* [ROS Melodic installation](ros-install.md)
|
||||
* [Camera calibration](camera_calibration.md)
|
||||
* [VPN ZeroTire Connection](zerotire_vpn.md)
|
||||
* [Quadcopter control with 4G communication](4g.md)
|
||||
* [Clover and Jetson Nano](jetson_nano.md)
|
||||
* [Remote control app](rc.md)
|
||||
@@ -76,7 +80,10 @@
|
||||
* [Interfacing with Arduino](arduino.md)
|
||||
* [Connecting GPS](gps.md)
|
||||
* [Working with IR sensors](ir_sensors.md)
|
||||
* [FPV Setup](fpv.md)
|
||||
* [FPV Setup](fpv_clover_4_2.md)
|
||||
* [FPV Setup (Clover 3)](fpv.md)
|
||||
* [Magnetic grip](magnetic_grip.md)
|
||||
* [Mechanical grip](mechanical_grip.md)
|
||||
* [Trainer mode](trainer_mode.md)
|
||||
* [Tinning](tinning.md)
|
||||
* [Types of power connectors](connectortypes.md)
|
||||
@@ -86,7 +93,13 @@
|
||||
* [Contribution Guidelines](contributing.md)
|
||||
* [Migration to v0.20](migrate20.md)
|
||||
* [Migration to v0.22](migrate22.md)
|
||||
* [Events](events.md)
|
||||
* [CopterHack-2021](copterhack2021.md)
|
||||
* [CopterHack-2019](copterhack2019.md)
|
||||
* [CopterHack-2018](copterhack2018.md)
|
||||
* [CopterHack-2017](copterhack2017.md)
|
||||
* [Clover-based projects](projects.md)
|
||||
* [Autonomous Multirotor Landing System (AMLS)](amls.md)
|
||||
* [Drone show](clever-show.md)
|
||||
* [Innopolis Open 2020 (L22_ÆRO)](innopolis_open_L22_AERO.md)
|
||||
* [Copter spheric guard](shield.md)
|
||||
@@ -94,8 +107,13 @@
|
||||
* [Android RC app](android.md)
|
||||
* [3D-scanning drone](3dscan.md)
|
||||
* [Human pose estimation drone control](human_pose_estimation_drone_control.md)
|
||||
* [Copter Hack 2019](copterhack2019.md)
|
||||
* [Copter Hack 2018](copterhack2018.md)
|
||||
* [Copter Hack 2017](copterhack2017.md)
|
||||
* [Robocross-2019](robocross2019.md)
|
||||
* [Camera calibration (legacy)](camera_calib.md)
|
||||
* [Recognition of crop types in agriculture](agriculture.md)
|
||||
* [Drones to fight Coronavirus](anticorona_drones.md)
|
||||
* [D-drone Copter Hack 2021 by AT Makers](ddrone.md)
|
||||
* [3D-printed Generative Design Frame](generative_design_frame.md)
|
||||
* [Retail Drone](bennie.md)
|
||||
* [The Indoor Mapping Drone](dromap.md)
|
||||
* [Seeding Drone](seeding_drone.md)
|
||||
* [Blue Jay Eindhoven](blue_jay_eindhoven.md)
|
||||
|
||||
147
docs/en/agriculture.md
Normal file
147
docs/en/agriculture.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# Recognition of crop types in mass agricultural production
|
||||
|
||||
## Introduction
|
||||
|
||||
Modern agriculture in many countries is becoming one of the shining examples of the rapid and successful introduction of new technologies. Unmanned aerial vehicles are capable of performing a wide range of tasks, among which monitoring of agricultural land has now become a common tool for increasing the efficiency of agriculture. The goal of my project is to write a code for recognizing crop types in mass agricultural production. In the future, from the recognition results, you can design a map of sown areas.
|
||||
|
||||
## Monitoring
|
||||
|
||||
In agriculture, monitoring is necessary to obtain information on the state of land and crops. Based on the monitoring results, farmers or specialists can understand whether crops are sprouting normally, whether there is a threat from weeds and/or insects - pests, what is the degree of moisture in individual areas or entire areas, etc.
|
||||
|
||||
## Explanation of the code
|
||||
|
||||
Import libraries:
|
||||
|
||||
```python
|
||||
import rospy
|
||||
import cv2
|
||||
from sensor_msgs.msg import Image
|
||||
from cv_bridge import CvBridge
|
||||
import numpy as np
|
||||
```
|
||||
|
||||
Create some variables:
|
||||
|
||||
```python
|
||||
rospy.init_node('computer_vision_sample')
|
||||
|
||||
bridge = CvBridge()
|
||||
|
||||
color = 'undefined'
|
||||
shape = 'undefined'
|
||||
culture = ""
|
||||
```
|
||||
|
||||
To implement computer vision algorithms, it is recommended to use the OpenCV library preinstalled on the Clover image.
|
||||
Create a subscriber for the topic with the image from the main camera for processing using OpenCV:
|
||||
|
||||
```python
|
||||
def image_colback_color(data):
|
||||
global color, shape
|
||||
|
||||
cv_image = bridge.imgmsg_to_cv2(data, 'bgr8') # OpenCV image
|
||||
img_hsv = cv2.cvtColor(cv_image, cv2.COLOR_BGR2HSV) #[118:119,158:159]
|
||||
|
||||
#detected color
|
||||
#print(img_hsv[0][0])
|
||||
```
|
||||
|
||||
Each culture has its unique shade (wheat is golden, buckwheat is light brown).
|
||||
|
||||
<img src="../assets/field.jpg" width="75%">
|
||||
<img src="../assets/field2.jpg" width="75%">
|
||||
|
||||
We describe color ranges for certain crops:
|
||||
|
||||
```python
|
||||
#wheat
|
||||
yellow_orange_low = (38, 110, 150)
|
||||
yellow_orange_high= (52, 110, 150)
|
||||
|
||||
#buckwheat
|
||||
brown_low = (23, 50, 50)
|
||||
brown_high= (37, 50, 50)
|
||||
|
||||
yellow_orange_mask = cv2.inRange(img_hsv, yellow_orange_low, yellow_orange_high)
|
||||
brown_mask = cv2.inRange(img_hsv, brown_low, brown_high)
|
||||
|
||||
if yellow_orange_mask[119][159] == 255:
|
||||
shape = shape_recog(yellow_orange_mask)
|
||||
|
||||
elif brown_mask[119][159] == 255:
|
||||
shape = shape_recog(brown_mask)
|
||||
|
||||
else:
|
||||
shape = 'undefined'
|
||||
color = 'undefined'
|
||||
|
||||
if shape = 'brown':
|
||||
culture = "greshiha"
|
||||
if shape = 'yellow_orange':
|
||||
culture = "pshenitsa"
|
||||
|
||||
image_sub = rospy.Subscriber('main_camera/image_raw', Image, image_colback_color)
|
||||
```
|
||||
|
||||
The script will take up to 100% CPU capacity. To slow down the script artificially, you can use throttling of frames from the camera, for example, at 5 Hz (`main_camera.launch`):
|
||||
|
||||
```xml
|
||||
<node pkg="topic_tools" name="cam_throttle" type="throttle" args="messages main_camera/image_raw 5.0 main_camera/image_raw_throttled"/>
|
||||
```
|
||||
|
||||
The topic for the subscriber, in this case, should be changed for `main_camera/image_raw_throttled`.
|
||||
|
||||
```python
|
||||
print (culture)
|
||||
while not rospy.is_shutdown():
|
||||
print("color: {}".format(color))
|
||||
print("shape: {}".format(shape))
|
||||
rospy.sleep(0.2)
|
||||
```
|
||||
|
||||
This program will recognize the culture by its shade. We can use more color ranges to improve the accuracy of the recognition so the drone can recognize more crops.
|
||||
|
||||
Examples of color ranges for other colors:
|
||||
|
||||
```python
|
||||
red_low1 = (0, 110, 150)
|
||||
red_high1 = (7, 255, 255)
|
||||
|
||||
red_low2 = (172, 110, 150)
|
||||
red_high2 = (180, 255, 255)
|
||||
|
||||
red_orange_low = (8, 110, 150)
|
||||
red_orange_high = (22, 110, 150)
|
||||
|
||||
orange_low = (23, 110, 150)
|
||||
orange_high = (37, 110, 150)
|
||||
|
||||
yellow_orange_low = (38, 110, 150)
|
||||
yellow_orange_high = (52, 110, 150)
|
||||
|
||||
yellow_low = (53, 150, 150)
|
||||
yellow_high = (67, 255, 255)
|
||||
|
||||
yellow_green_low = (68, 150, 150)
|
||||
yellow_green_high = (82, 255, 255)
|
||||
|
||||
green_low = (83, 150, 150)
|
||||
green_high = (97, 255, 255)
|
||||
|
||||
blue_green_low = (98, 150, 150)
|
||||
blue_green_high = (113, 255, 255)
|
||||
|
||||
blue_low = (114, 150, 150)
|
||||
blue_high = (127, 255, 255)
|
||||
|
||||
blue_violet_low = (128, 150, 150)
|
||||
blue_violet_high = (142, 255, 255)
|
||||
|
||||
violet_low = (143, 150, 150)
|
||||
violet_high = (157, 255, 255)
|
||||
|
||||
red_violet_low = (158, 150, 150)
|
||||
red_violet_hugh = (171, 255, 255)
|
||||
```
|
||||
|
||||
Note that there are two ranges for red because red is at the edges of the HSV color space.
|
||||
672
docs/en/amls.md
Normal file
672
docs/en/amls.md
Normal file
@@ -0,0 +1,672 @@
|
||||
# Autonomous Multirotor Landing System (AMLS)
|
||||
|
||||
|
||||
|
||||
## The goal is to automatically land a drone on a moving platform
|
||||
|
||||
### AMLS Article
|
||||
|
||||
In this Article we will describe AMLS project. Namely, AMLS Optical stabilization, GPS holding, GPS following, Altitude holding, Grabbing, Weather protection, Speed measurement and Illumination systems. In addition, we will make clear of how it works and how it was done!
|
||||
|
||||
### Our main GitHub repository
|
||||
|
||||
https://github.com/XxOinvizioNxX/Liberty-Way
|
||||
|
||||
### Developers
|
||||
|
||||
- [Pavel Neshumov](mailto:xxoinvizionxx@gmail.com)
|
||||
- [Andrey Kabalin](mailto:astik452@gmail.com)
|
||||
- [Vladislav Yasnetsky](mailto:vlad.yasn@gmail.com)
|
||||
|
||||
|
||||
|
||||
-----------
|
||||
|
||||
## Table of contents
|
||||
|
||||
- [0. How does it work?](#how-does-it-work)
|
||||
- [0.1. A video about our project](#short-video-about-our-project-clickable)
|
||||
- [1. GPS hold and Flight to waypoints functions](#hold-and-flight-to-waypoints-functions)
|
||||
- [1.1. Serial reading](#serial-reading)
|
||||
- [1.2. UBlox GPS parsing](#ublox-parsing)
|
||||
- [1.3. Set current waypoint](#set-current-waypoint)
|
||||
- [1.4. Waypoint edition (To fly to waypoints)](#waypoint-edit-to-fly-to-waypoints)
|
||||
- [1.5. Waypoint stabilization](#waypoint-stabilization)
|
||||
- [2. GPS following](#following)
|
||||
- [3. Compass](#compass)
|
||||
- [4. Altitude stabilization (barometer)](#altitude-stabilization-barometer)
|
||||
- [5. Optical stabilization](#optical-stabilization)
|
||||
- [5.1. So difficult and so important](#so-difficult-and-so-important)
|
||||
- [5.2. First steps](#first-steps)
|
||||
- [5.3. Inverse approach](#inverse-approach)
|
||||
- [5.4. Java edition](#java-edition)
|
||||
- [5.5. Liberty-Way](#liberty-way)
|
||||
- [5.6. Communication with the drone](#communication-with-the-drone)
|
||||
- [5.7. Camera gimbal](#camera-gimbal)
|
||||
- [6. Eitude AMLS Platform](#eitude-amls-platform)
|
||||
- [6.1. Grabbing system](#grabbing-system)
|
||||
- [6.2. Weather protection system](#weather-protection-system)
|
||||
- [6.3. Speed measurement system](#platform-speedometer)
|
||||
- [6.4. Illumination system](#platform-light-sensor)
|
||||
- [7. Conclusion](#conclusion)
|
||||
|
||||
-----------
|
||||
|
||||
## 0. How does it work? {#how-does-it-work}
|
||||
|
||||
The AMLS system consists of two parts:
|
||||
|
||||
- The drone
|
||||
|
||||
|
||||
|
||||
- And the platform either mobile (implemented on a vehicle), either stable (pick-up-point)
|
||||
|
||||
|
||||
|
||||
How the system operates:
|
||||
|
||||
- Firstly, a drone with a delivery package is far from the platform and it has no visual contact with it. The drone recieves GPS coordinates of a platform by using cellular communication or any other radio channel (The drone has Liberty-Link implemented on it. This module is able to adjust its position, whatever the firmware of the flight controller. The module is installed inside the line between a receiver and a flight controller.
|
||||
- The drone is moving to received coordinates. The coordinates might be renewed in the process (but not frequently, thus preventing the channel from overloading)
|
||||
- When the drone is close to the platform but there is still no visual contact, the program runs GPS stabilization. Here the data is being transmitted over the closest radio communication channel of high freqency, so the drone can catch up with the platform.
|
||||
- Meanwhile, the drone descends (barometers are installed on both, the drone and the platform). Descending goes on untill altitude reaches 1.5-2 meters above the platform.
|
||||
- While descending and when visual contact with the platform camera is established, the program enables visual (precision) stabilization. And as soon as the drone's tag is within camera's field of view, the algorithm will capture the drone.
|
||||
- When optical stabilization is enabled, GPS is working as a back up plan (in case something goes wrong, GPS stabilization launches again).
|
||||
- In order to use optical stabilization the drone is equipped with ArUco tag which can be captured by a camera and by using the closest radio communication channel, the system transmits adjustment data to the drone.
|
||||
- Along with optical stabilization, the program launches landing algorithm. The algorithm artificially and smoothly reduces the setpoint of height (Z) until it reaches a certain threshold.
|
||||
- When the drone is approaching on the desirable height, the program enables grabbing system implemented on the platform. Those grips are used to catch and hold the drone in the process of landing and after the drone was caught.
|
||||
- When the landing is completed, the platform starts maintenance work and in order to protect the drone frome external influences, the program enables weather protection and closes the roof above landing area.
|
||||
- Landing accomplished!
|
||||
|
||||
### Short video about our project (clickable) {#short-video-about-our-project-clickable}
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/6qjS-iq6a3k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
## 1. GPS hold and Flight to waypoints functions {#hold-and-flight-to-waypoints-functions}
|
||||
|
||||
At the beginning, the drone with the package is far from the platform. Then via cellular communication or another suitable radio channel, platform GPS coordinates are sent to the drone (the Liberty-Link module is installed on the drone, this module is capable of correcting its position, regardless of the firmware of the flight controller. (The module is placed between the receiver (RC) and the flight controller)
|
||||
|
||||
GPS module will be built in Liberty-Link, so it would have the ability to maintain the drone's GPS position and follow GPS points.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/x364giIt6lc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
GPS-module will be used from the UBlox group (for instance, UBlox Neo-M8). There will be 1 or 3 (to minimize the error) modules.
|
||||
|
||||
|
||||
|
||||
Modules operate via UART, configured to send data 5 times per second. The Liberty-Link firmware will read data from the modules and calculate the coordinates of the current position.
|
||||
|
||||
### 1.1. Serial reading {#serial-reading}
|
||||
|
||||
Reading data from a module into a buffer looks like this:
|
||||
|
||||
```cpp
|
||||
// Read data from the GPS module
|
||||
while (GPS_serial.available() && new_line_found == 0) {
|
||||
// Stay in this loop as long as there is serial information from the GPS available
|
||||
char read_serial_byte = GPS_serial.read();
|
||||
if (read_serial_byte == '$') {
|
||||
// Clear the old data from the incoming buffer array if the new byte equals a $ character
|
||||
for (message_counter = 0; message_counter <= 99; message_counter++) {
|
||||
incoming_message[message_counter] = '-';
|
||||
}
|
||||
// Reset the message_counter variable because we want to start writing at the begin of the array
|
||||
message_counter = 0;
|
||||
}
|
||||
// If the received byte does not equal a $ character, increase the message_counter variable
|
||||
else if (message_counter <= 99)
|
||||
message_counter++;
|
||||
|
||||
// Write the new received byte to the new position in the incoming_message array
|
||||
incoming_message[message_counter] = read_serial_byte;
|
||||
|
||||
// Every NMEA line ends with a '*'. If this character is detected the new_line_found variable is set to 1
|
||||
if (read_serial_byte == '*') new_line_found = 1;
|
||||
}
|
||||
```
|
||||
|
||||
### 1.2. UBlox GPS parsing {#ublox-parsing}
|
||||
|
||||
After that, latitude, longitude, a type of correction (2D, 3D) and the number of satellites are calculated from the filled buffer.
|
||||
Parsing GPS data of the UBlox protocol looks like this:
|
||||
|
||||
```cpp
|
||||
// If the software has detected a new NMEA line it will check if it's a valid line that can be used
|
||||
if (new_line_found == 1) {
|
||||
// Reset the new_line_found variable for the next line
|
||||
new_line_found = 0;
|
||||
if (incoming_message[4] == 'L' && incoming_message[5] == 'L' && incoming_message[7] == ',') {
|
||||
// When there is no GPS fix or latitude/longitude information available
|
||||
// Set some variables to 0 if no valid information is found by the GPS module. This is needed for the GPS loss when flying
|
||||
l_lat_gps = 0;
|
||||
l_lon_gps = 0;
|
||||
lat_gps_previous = 0;
|
||||
lon_gps_previous = 0;
|
||||
number_used_sats = 0;
|
||||
}
|
||||
// If the line starts with GA and if there is a GPS fix we can scan the line for the latitude, longitude and number of satellites
|
||||
if (incoming_message[4] == 'G' && incoming_message[5] == 'A' && (incoming_message[44] == '1' || incoming_message[44] == '2')) {
|
||||
// Filter the minutes for the GGA line multiplied by 10
|
||||
lat_gps_actual = ((int)incoming_message[19] - 48) * (long)10000000;
|
||||
lat_gps_actual += ((int)incoming_message[20] - 48) * (long)1000000;
|
||||
lat_gps_actual += ((int)incoming_message[22] - 48) * (long)100000;
|
||||
lat_gps_actual += ((int)incoming_message[23] - 48) * (long)10000;
|
||||
lat_gps_actual += ((int)incoming_message[24] - 48) * (long)1000;
|
||||
lat_gps_actual += ((int)incoming_message[25] - 48) * (long)100;
|
||||
lat_gps_actual += ((int)incoming_message[26] - 48) * (long)10;
|
||||
// To convert minutes to degrees we need to divide minutes by 6
|
||||
lat_gps_actual /= (long)6;
|
||||
// Add multiply degrees by 10
|
||||
lat_gps_actual += ((int)incoming_message[17] - 48) * (long)100000000;
|
||||
lat_gps_actual += ((int)incoming_message[18] - 48) * (long)10000000;
|
||||
// Divide everything by 10
|
||||
lat_gps_actual /= 10;
|
||||
|
||||
// Filter minutes for the GGA line multiplied by 10
|
||||
lon_gps_actual = ((int)incoming_message[33] - 48) * (long)10000000;
|
||||
lon_gps_actual += ((int)incoming_message[34] - 48) * (long)1000000;
|
||||
lon_gps_actual += ((int)incoming_message[36] - 48) * (long)100000;
|
||||
lon_gps_actual += ((int)incoming_message[37] - 48) * (long)10000;
|
||||
lon_gps_actual += ((int)incoming_message[38] - 48) * (long)1000;
|
||||
lon_gps_actual += ((int)incoming_message[39] - 48) * (long)100;
|
||||
lon_gps_actual += ((int)incoming_message[40] - 48) * (long)10;
|
||||
// To convert minutes to degrees we need to divide minutes by 6
|
||||
lon_gps_actual /= (long)6;
|
||||
// Add multiply degrees by 10
|
||||
lon_gps_actual += ((int)incoming_message[30] - 48) * (long)1000000000;
|
||||
lon_gps_actual += ((int)incoming_message[31] - 48) * (long)100000000;
|
||||
lon_gps_actual += ((int)incoming_message[32] - 48) * (long)10000000;
|
||||
// Divide everything by 10
|
||||
lon_gps_actual /= 10;
|
||||
|
||||
if (incoming_message[28] == 'N')
|
||||
// When flying north of the equator the latitude_north variable will be set to 1
|
||||
latitude_north = 1;
|
||||
else
|
||||
// When flying south of the equator the latitude_north variable will be set to 0
|
||||
latitude_north = 0;
|
||||
|
||||
if (incoming_message[42] == 'E')
|
||||
// When flying east of the prime meridian the longiude_east variable will be set to 1
|
||||
longiude_east = 1;
|
||||
else
|
||||
// When flying west of the prime meridian the longiude_east variable will be set to 0
|
||||
longiude_east = 0;
|
||||
|
||||
// Filter the number of satillites from the GGA line
|
||||
number_used_sats = ((int)incoming_message[46] - 48) * (long)10;
|
||||
number_used_sats += (int)incoming_message[47] - 48;
|
||||
|
||||
if (lat_gps_previous == 0 && lon_gps_previous == 0) {
|
||||
// If this is the first time the GPS code is used
|
||||
// Set the lat_gps_previous variable to the lat_gps_actual variable
|
||||
lat_gps_previous = lat_gps_actual;
|
||||
// Set the lon_gps_previous variable to the lon_gps_actual variable
|
||||
lon_gps_previous = lon_gps_actual;
|
||||
}
|
||||
|
||||
// Divide the difference between the new and the previous latitudes by 10
|
||||
lat_gps_loop_add = (float)(lat_gps_actual - lat_gps_previous) / 10.0;
|
||||
// Divide the difference between the new and the previous longitudes by 10
|
||||
lon_gps_loop_add = (float)(lon_gps_actual - lon_gps_previous) / 10.0;
|
||||
|
||||
// Set the l_lat_gps variable to the previous latitude value
|
||||
l_lat_gps = lat_gps_previous;
|
||||
// Set the l_lon_gps variable to the previous longitude value
|
||||
l_lon_gps = lon_gps_previous;
|
||||
|
||||
// Remember the new latitude value in the lat_gps_previous variable for the next loop
|
||||
lat_gps_previous = lat_gps_actual;
|
||||
// Remember the new longitude value in the lat_gps_previous variable for the next loop
|
||||
lon_gps_previous = lon_gps_actual;
|
||||
}
|
||||
|
||||
// If the line starts with SA and if there is a GPS fix we can scan the line for the fix type (none, 2D or 3D)
|
||||
if (incoming_message[4] == 'S' && incoming_message[5] == 'A')
|
||||
fix_type = (int)incoming_message[9] - 48;
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
### 1.3. Set current waypoint {#set-current-waypoint}
|
||||
|
||||
When required data is received the main magic happens. To enable maintaining of the current position it will be enough to set the flag `waypoint_set = 1;` and set current coordinates as a waypoint:
|
||||
|
||||
```cpp
|
||||
l_lat_waypoint = l_lat_gps;
|
||||
l_lon_waypoint = l_lon_gps;
|
||||
```
|
||||
|
||||
After that, the calculation of the error in the coordinates will begin, correction works with the help of a PD - regulator. For D - component we use rotation memory.
|
||||
|
||||
### 1.4. Waypoint edit (To fly to waypoints) {#waypoint-edit-to-fly-to-waypoints}
|
||||
|
||||
If you just set the new `l_lat_waypoint` and `l_lon_wayoint`, which are located at a great distance from the drone, the drone will not be able to fly normally and stabilize at these coordinates. For smooth adjustments `l_lat_gps_float_adjust` and `l_lon_gps_float_adjust` can be used. These are `float` variables, changing which will smoothly shift `l_lat_waypoint` and `l_lon_waypoint`.
|
||||
|
||||
For example, if in the main loop you will constantly add a certain value to these variables:
|
||||
|
||||
```cpp
|
||||
l_lat_gps_float_adjust += 0.0015;
|
||||
```
|
||||
|
||||
With set waypoint, the drone will move smoothly in the given direction.
|
||||
In the future, this will be used for the smooth drone's acceleration and deceleration while moving to its destination.
|
||||
|
||||
### 1.5. Waypoint stabilization {#waypoint-stabilization}
|
||||
|
||||
```cpp
|
||||
if (waypoint_set == 1) {
|
||||
//If the waypoints are stored
|
||||
|
||||
// Adjust l_lat_waypoint
|
||||
if (l_lat_gps_float_adjust > 1) {
|
||||
l_lat_waypoint++;
|
||||
l_lat_gps_float_adjust--;
|
||||
}
|
||||
if (l_lat_gps_float_adjust < -1) {
|
||||
l_lat_waypoint--;
|
||||
l_lat_gps_float_adjust++;
|
||||
}
|
||||
|
||||
// Adjust l_lon_waypoint
|
||||
if (l_lon_gps_float_adjust > 1) {
|
||||
l_lon_waypoint++;
|
||||
l_lon_gps_float_adjust--;
|
||||
}
|
||||
if (l_lon_gps_float_adjust < -1) {
|
||||
l_lon_waypoint--;
|
||||
l_lon_gps_float_adjust++;
|
||||
}
|
||||
|
||||
// Calculate the latitude error between waypoint and actual position
|
||||
gps_lon_error = l_lon_waypoint - l_lon_gps;
|
||||
// Calculate the longitude error between waypoint and actual position
|
||||
gps_lat_error = l_lat_gps - l_lat_waypoint;
|
||||
|
||||
// Subtract the current memory position to make room for the new value
|
||||
gps_lat_total_avarage -= gps_lat_rotating_mem[gps_rotating_mem_location];
|
||||
// Calculate the new change between the actual pressure and the previous measurements
|
||||
gps_lat_rotating_mem[gps_rotating_mem_location] = gps_lat_error - gps_lat_error_previous;
|
||||
// Add the new value to the long term average value
|
||||
gps_lat_total_avarage += gps_lat_rotating_mem[gps_rotating_mem_location];
|
||||
|
||||
// Subtract the current memory position to make room for the new value
|
||||
gps_lon_total_avarage -= gps_lon_rotating_mem[gps_rotating_mem_location];
|
||||
// Calculate the new change between the actual pressure and the previous measurements
|
||||
gps_lon_rotating_mem[gps_rotating_mem_location] = gps_lon_error - gps_lon_error_previous;
|
||||
// Add the new value to the long term avarage value
|
||||
gps_lon_total_avarage += gps_lon_rotating_mem[gps_rotating_mem_location];
|
||||
|
||||
// Increase the rotating memory location
|
||||
gps_rotating_mem_location++;
|
||||
if (gps_rotating_mem_location == 35)
|
||||
// Start at 0 when the memory location 35 is reached
|
||||
gps_rotating_mem_location = 0;
|
||||
|
||||
// Remember the error for the next loop
|
||||
gps_lat_error_previous = gps_lat_error;
|
||||
gps_lon_error_previous = gps_lon_error;
|
||||
|
||||
//Calculate the GPS pitch and roll corrections as if the nose of the multicopter is facing north.
|
||||
//The Proportional part = (float)gps_lat_error * gps_p_gain.
|
||||
//The Derivative part = (float)gps_lat_total_avarage * gps_d_gain.
|
||||
gps_pitch_adjust_north = (float)gps_lat_error * gps_p_gain + (float)gps_lat_total_avarage * gps_d_gain;
|
||||
gps_roll_adjust_north = (float)gps_lon_error * gps_p_gain + (float)gps_lon_total_avarage * gps_d_gain;
|
||||
|
||||
if (!latitude_north)
|
||||
// Invert the pitch adjustmet because the quadcopter is flying south of the equator
|
||||
gps_pitch_adjust_north *= -1;
|
||||
if (!longiude_east)
|
||||
// Invert the roll adjustmet because the quadcopter is flying west of the prime meridian
|
||||
gps_roll_adjust_north *= -1;
|
||||
|
||||
//Because the correction is calculated as if the nose was facing north, we need to convert it for the current heading.
|
||||
gps_roll_adjust = ((float)gps_roll_adjust_north * cos(angle_yaw * 0.017453)) + ((float)gps_pitch_adjust_north * cos((angle_yaw - 90) * 0.017453));
|
||||
gps_pitch_adjust = ((float)gps_pitch_adjust_north * cos(angle_yaw * 0.017453)) + ((float)gps_roll_adjust_north * cos((angle_yaw + 90) * 0.017453));
|
||||
|
||||
//Limit the maximum correction to 300. This way we still have the full control of the drone with the pitch and roll sticks on the transmitter.
|
||||
if (gps_roll_adjust > 300) gps_roll_adjust = 300;
|
||||
if (gps_roll_adjust < -300) gps_roll_adjust = -300;
|
||||
if (gps_pitch_adjust > 300) gps_pitch_adjust = 300;
|
||||
if (gps_pitch_adjust < -300) gps_pitch_adjust = -300;
|
||||
}
|
||||
```
|
||||
|
||||
## 2. GPS following {#following}
|
||||
|
||||
The main part of stabilization using GPS coordinates was the development of an algorithm for predicting the position of the drone. The simplest idea was to use a mathematical calculation of the next drone's position. This is calculated for the most accurate positioning in relation to the landing platform.
|
||||
|
||||
At the beginning we developed a simple algorithm for calculating the coefficient of coordinates' change. The development was done using Python. At the stage of testing this algorithm, the problem of simulating the generation of GPS coordinates arose. To solve this problem, many different resources were used: from open source homemade navigators to trying to use the Google Maps, Yandex Maps or 2GIS APIs.
|
||||
And only after 3 months, we thought of a simple solution: to change the values with some delta and to visualize using MatPlotLib or PyQtGraph.
|
||||
Prior to this, all testing of the algorithm was carried out using the PX4 firmware toolkit and the Gazebo drone motion simulator. As a result, many formalities were overcome in terms of communicating with the simulator and increasing performance (click on the picture to see the video).
|
||||
|
||||
The result of the GPS prediction (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/Rg-Y_fl4BKQ" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
The end result reached a point when the error of the predicted position varies from 0 to 70 centimeters.
|
||||
|
||||
-----------
|
||||
|
||||
## 3. Compass {#compass}
|
||||
|
||||
Before optical stabilization launches (during GPS stabilization process), to calculate the GPS correction vector, you need to know the exact angle from the compass. For this, a compass built into the GPS module is used.
|
||||
|
||||
Because during the flight, the roll and pitch angles change and a user needs to correct the values from the compass.
|
||||
In general, calculating the angle from the compass looks like this:
|
||||
|
||||
```cpp
|
||||
// The compass values change when the roll and pitch angles of the quadcopter change. That's the reason why the x and y values need to be calculated for a virtual horizontal position
|
||||
// The 0.0174533 value is phi/180 as the functions are in radians in stead of degrees
|
||||
compass_x_horizontal = (float)compass_x * cos(angle_pitch * -0.0174533) + (float)compass_y * sin(angle_roll * 0.0174533) * sin(angle_pitch * -0.0174533) - (float)compass_z * cos(angle_roll * 0.0174533) * sin(angle_pitch * -0.0174533);
|
||||
compass_y_horizontal = (float)compass_y * cos(angle_roll * 0.0174533) + (float)compass_z * sin(angle_roll * 0.0174533);
|
||||
|
||||
// Now that the horizontal values are known the heading can be calculated. With the following lines of code the heading is calculated in degrees.
|
||||
// Please note that the atan2 uses radians in stead of degrees. That is why the 180/3.14 is used.
|
||||
if (compass_y_horizontal < 0)actual_compass_heading = 180 + (180 + ((atan2(compass_y_horizontal, compass_x_horizontal)) * (180 / 3.14)));
|
||||
else actual_compass_heading = (atan2(compass_y_horizontal, compass_x_horizontal)) * (180 / 3.14);
|
||||
|
||||
// Add the declination to the magnetic compass heading to get the geographic north
|
||||
actual_compass_heading += declination;
|
||||
// If the compass heading becomes smaller than 0, 360 is added to keep it in the 0-360 degrees range
|
||||
if (actual_compass_heading < 0) actual_compass_heading += 360;
|
||||
// If the compass heading becomes larger then 360, 360 is subtracted to keep it in the 0-360 degrees range
|
||||
else if (actual_compass_heading >= 360) actual_compass_heading -= 360;
|
||||
```
|
||||
|
||||
It is clear that the angle from the compass can also be used to maintain the yaw angle of the drone. With point-to-point flights, this may be realized. But at the moment, there is no urgent need for this, because after the start of optical stabilization, the algorithm is able to correct the drone regardless of its yaw angle. Also, during optical stabilization, the yaw angle is automatically corrected.
|
||||
|
||||
-----------
|
||||
|
||||
## 4. Altitude stabilization (barometer) {#altitude-stabilization-barometer}
|
||||
|
||||
Before optical stabilization launches (during GPS stabilization process), our Liberty-Link module will be able to maintain altitude using a barometer.
|
||||
|
||||
The platform, as well as the Liberty-Link, will have MS5611 barometers.
|
||||
|
||||
|
||||
|
||||
According to the documentation, the height resolution is 10 cm. The algorithm will take the pressure values and by passing it through the PID-controller will stabilize the drone's altitude by changing the Throttle (3rd channel).
|
||||
|
||||
Altitude hold test (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/xmvcGeZzEfc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
During the flight along the waypoint, the setpoint of the pressure will decrease in order to increase the altitude (it is safer to fly in a straight line at a high altitude, so the drone would not crash into anything). And during GPS stabilization (when the drone is already close to the platform), the drone will be set with a setpoint of pressure that correlates with ~ 1.5-2m height above the platform.
|
||||
|
||||
-----------
|
||||
|
||||
## 5. Optical stabilization {#optical-stabilization}
|
||||
|
||||
### 5.1. So difficult and so important {#so-difficult-and-so-important}
|
||||
|
||||
Optical stabilization is the most important and challenging part of our project. In the current condition it is possible to keep the drone above the platform still only using these algorithms. The current version of the OIS algorithm, along with a description of the usage and making, is available in our main GitHub repository. In the future, GPS stabilization will be added to it.
|
||||
|
||||
### 5.2. First steps {#first-steps}
|
||||
|
||||
And as we couldn't predict the possibility of accomplishing our task, first of all, we started to think about the solution for the stabilization system. Afterwards, we settled with the stabilization using augmented reality tags. Firstly, it won't take much finances as we do not need GPS or RTK systems and it will be accurate enough to accomplish its purpose.
|
||||
Our first idea was to attach Raspberry Pi with Liberty_X as it was embodied in COEX Clover and to let Raspberry Pi handle all of the maths.
|
||||
|
||||
First optical stabilization prototype test (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/TrrxXOHAqbQ" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
But few tests showed that Raspberry Pi computing power is not enough for amount of data needed to stabilize the drone. Furthermore, the idea of installing a Raspberry Pi on each drone is irrational for its own.
|
||||
|
||||
Also, we had middling prototypes, for example, attempts to use color markers (circles of different colors), but these ideas did not work well enough.
|
||||
|
||||
### 5.3. Inverse approach {#inverse-approach}
|
||||
|
||||
Then we came up with the idea of separating drone and stabilization system so the main math will be accomplished on the landing platform with powerful machine.
|
||||
|
||||
This was how we ended up with our current optical stabilization algorithm - the camera which is connected to a powerful machine and the machine is attached to the platform. The drone only has 4x4 ArUco tag and its controller.
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/A2oq6zCebVo" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
Then, we came up with using Pose Estimation algorithms from OpenCV library. The first tests showed us that we are on the right track!
|
||||
|
||||
Pose Estimation Python (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/kE3UmJZ00so" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
But, the algorithms were far from perfect. For example, since the code was written in Python (https://github.com/XxOinvizioNxX/Liberty-X_Point), the performance was not satisfyingly, and there was no suitable threading control either. Therefore, we had to change something.
|
||||
|
||||
### 5.4. Java edition {#java-edition}
|
||||
|
||||
Having weighed all the pros and cons, it was decided to rewrite all optical stabilization using Java. This is how the first version of Liberty-Way appeared. This time, it was decided to approach the OOP thoroughly, and, after a little tweaking, an excellent stabilization and landing algorithm was obtained.
|
||||
|
||||
Landing test on Liberty-Way v.beta_0.0.1 (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8VAobWPFG8g" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### 5.5. Liberty-Way {#liberty-way}
|
||||
|
||||
Then many improvements and bug fixes followed. As a result, Liberty-Way is a cross-platform web sarvar application that is very convenient for configuration and debugging. Also, in the latest versions (beta_1.0.3 - beta_1.1.2) a blackbox feature was introduced (for recording logs), as well as communication with the platform and many other necessary algorithms.
|
||||
|
||||
Full description, including all settings, startup, etc. you can find in our GitHub repository: https://github.com/XxOinvizioNxX/Liberty-Way
|
||||
|
||||
Video of static stabilization (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/adR38R27MEU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
Liberty-Way can even stabilize a "thrown" drone (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/gAaGQSC-r2g" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
There is a small bug in the video with the rotation angle, in the new release it has been fixed!
|
||||
|
||||
And, of course, example of how it works in motion (tested with beta_0.0.3 release) (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8vB-8QIBoJU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
All basic settings are conveniently placed in separate JSON files (settings, PID), which allows a user to quickly change the required parameters without rebuilding the application. In fact, to run the application, you just need to download the latest release, unpack the archive and run it through the launcher corresponding to the preferable OS.
|
||||
|
||||
### 5.6. Communication with the drone {#communication-with-the-drone}
|
||||
|
||||
The Liberty-Way connects to the Liberty-Link module installed on the drone and adjusts its position by directly controlling four main channels of the remote control. In one cycle (each frame from the camera), 12 bytes of correction data are sent to the module:
|
||||
|
||||
|
||||
Bytes description:
|
||||
|
||||
- **Roll bytes** - Roll correction values
|
||||
- **Pitch bytes** - Pitch correction values
|
||||
- **Yaw bytes** - Yaw correction values
|
||||
- **Altitude bytes** - Altitude correction values
|
||||
- **Service info** - sets the drone state (0 - Nothing to do, 1 - Stabilization, 2 - Landing (command not implemented and will be removed in the future. This is not a real landing, just to tell the drone to start decreasing altitude), 3 - Disable motors)
|
||||
- **Check byte** - XOR sum of all previous bytes that is compared via transmittion in order to verify the data
|
||||
- **Data suffix** - unique pair of ASCII symbols that is not represented in the packet in any form and that shows the end of the packet
|
||||
|
||||
On the drone side (Liberty-Link module), data reading is performing as follows:
|
||||
|
||||
```cpp
|
||||
while (Telemetry_serial.available()) {
|
||||
tdc_receive_buffer[tdc_receive_buffer_counter] = Telemetry_serial.read();
|
||||
if (tdc_receive_byte_previous == 'L' && tdc_receive_buffer[tdc_receive_buffer_counter] == 'X') {
|
||||
tdc_receive_buffer_counter = 0;
|
||||
if (tdc_receive_start_detect >= 2) {
|
||||
tdc_check_byte = 0;
|
||||
for (tdc_temp_byte = 0; tdc_temp_byte <= 8; tdc_temp_byte++)
|
||||
tdc_check_byte ^= tdc_receive_buffer[tdc_temp_byte];
|
||||
if (tdc_check_byte == tdc_receive_buffer[9]) {
|
||||
direct_roll_control = (uint32_t)tdc_receive_buffer[1] | (uint32_t)tdc_receive_buffer[0] << 8;
|
||||
direct_pitch_control = (uint32_t)tdc_receive_buffer[3] | (uint32_t)tdc_receive_buffer[2] << 8;
|
||||
direct_yaw_control = (uint32_t)tdc_receive_buffer[5] | (uint32_t)tdc_receive_buffer[4] << 8;
|
||||
direct_throttle_control = (uint32_t)tdc_receive_buffer[7] | (uint32_t)tdc_receive_buffer[6] << 8;
|
||||
direct_service_info = (uint32_t)tdc_receive_buffer[8];
|
||||
|
||||
if (direct_roll_control > 1100 && direct_roll_control < 1900 &&
|
||||
direct_pitch_control > 1100 && direct_pitch_control < 1900 &&
|
||||
direct_yaw_control > 1100 && direct_yaw_control < 1900 &&
|
||||
direct_throttle_control > 1100 && direct_throttle_control < 1900 &&
|
||||
/*flight_mode == 2 &&*/ channel_7 > 1500) {
|
||||
tdc_timer = millis();
|
||||
tdc_working = 1;
|
||||
}
|
||||
else
|
||||
tdc_working = 0;
|
||||
}
|
||||
else {
|
||||
direct_roll_control = 1500;
|
||||
direct_pitch_control = 1500;
|
||||
tdc_working = 0;
|
||||
}
|
||||
} else
|
||||
tdc_receive_start_detect++;
|
||||
}
|
||||
else {
|
||||
tdc_receive_byte_previous = tdc_receive_buffer[tdc_receive_buffer_counter];
|
||||
tdc_receive_buffer_counter++;
|
||||
if (tdc_receive_buffer_counter > 11)tdc_receive_buffer_counter = 0;
|
||||
}
|
||||
}
|
||||
if (millis() - tdc_timer >= 500) {
|
||||
tdc_working = 0;
|
||||
}
|
||||
if (tdc_working && direct_service_info == 2 && !return_to_home_step)
|
||||
return_to_home_step = 3;
|
||||
if (!tdc_working)
|
||||
return_to_home_step = 0;
|
||||
if (!tdc_working || direct_service_info < 1) {
|
||||
direct_roll_control = 1500;
|
||||
direct_pitch_control = 1500;
|
||||
direct_yaw_control = 1500;
|
||||
direct_throttle_control = 1500;
|
||||
}
|
||||
```
|
||||
|
||||
As a result, there are 4 variables:
|
||||
|
||||
```
|
||||
direct_roll_control
|
||||
direct_pitch_control
|
||||
direct_yaw_control
|
||||
direct_throttle_control
|
||||
```
|
||||
|
||||
Which are directly added to the data received from the control panel.
|
||||
Probably, in the future, other data will be added, at least for working with GPS. Stay tuned for updates in our repository.
|
||||
|
||||
### 5.7. Camera gimbal {#camera-gimbal}
|
||||
|
||||
To operate our system in real conditions, it is required to minimize camera shaking if we don't want to lose the tag on the drone. For that reason, a 3D model of a gimbal for attaching the drone to the platform was developed to stabilize a conventional webcam.
|
||||
|
||||
Camera mount:
|
||||
|
||||
|
||||
|
||||
Camera wire fixing (ferrite filter on the wire):
|
||||
|
||||
|
||||
|
||||
Fixing of the "crabs" latches on the suspension substrate:
|
||||
|
||||
|
||||
|
||||
An approximate view of the assembly of the entire suspension mechanism:
|
||||
|
||||
|
||||
|
||||
-----------
|
||||
|
||||
## 6. Eitude AMLS Platform {#eitude-amls-platform}
|
||||
|
||||
The platform is an interconnected system for landing the drone. The platform was planned to be controlled via the Serial interface, using the G-Code commands: The current platform code can be found in the Eitude GitHub repository: https://github.com/XxOinvizioNxX/Eitude
|
||||
|
||||
### 6.1. Grabbing system {#grabbing-system}
|
||||
|
||||
As you may know it doesn't matter how good is our stabilization, without grabbing system the drone will crash eventually. Hence we developed a 3D model of a grabbing system with 4 grips that have a hook at the end of each one. This will allow the system to slowly grab the drone while it lands and hold it steady after landing.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 6.2. Weather protection system {#weather-protection-system}
|
||||
|
||||
As for the weather protection, we developed a 3D model to create a roof that will protect the drone from weather conditions while it is on the platform.
|
||||
The AMLS weather protection system consists of scissor-like mechanisms covered with a canvas, which are located around the edges of the platform.
|
||||
After a successful landing, the mechanisms on both sides of the platform close and protect the drone from external influences. The roof structure itself makes it light and strong, and the scissor-like mechanisms allow it to simply fold and unfold itself. Moreover, the assembly of such mechanisms will be simple and reliable.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 6.3. Platform speedometer {#platform-speedometer}
|
||||
|
||||
In order to land on a quickly moving platform, it is very useful to know its speed. For now, the platform does not have a GPS module, or any other way to measure absolute speed. Therefore, for a temporary solution to this problem, it was decided to calculate the speed using an accelerometer. For example, MPU6050. The IMU is mounted into the prototype platform through a soft backing and it's covered with a cap to protect it from the wind. The stabilization algorithm (Liberty-Way) sends a request to the platform `L1` to test the speed. A message `S0 L <speed in km / h>` is returned as a response.
|
||||
|
||||
|
||||
|
||||
Speedometer test (inside the gray circle, lower right parameter (SPD) - speed in km / h) (Clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/yvCo6tYjdM0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
To calculate the speed, the acceleration is taken for short time periods, then multiplied with time, which results with the instantaneous speed. Then this speed is constantly added to the previous value:
|
||||
|
||||
```cpp
|
||||
void speed_handler(void) {
|
||||
gyro_signalen();
|
||||
|
||||
// Filter accelerations
|
||||
acc_x_filtered = (float)acc_x_filtered * ACC_FILTER_KOEFF + (float)acc_x * (1.0 - ACC_FILTER_KOEFF);
|
||||
|
||||
speed = acc_x_filtered;
|
||||
// Convert acceleration to G
|
||||
speed /= 4096.0;
|
||||
// Convert to m/s^2
|
||||
speed *= 9.81;
|
||||
// Multiply by dt to get instant speed in m/ms
|
||||
speed *= (millis() - speed_loop_timer);
|
||||
|
||||
// Reset timer
|
||||
speed_loop_timer = millis();
|
||||
|
||||
// Convert to m/s
|
||||
speed /= 1000.0;
|
||||
// Convert to km/h
|
||||
speed *= 3.6;
|
||||
|
||||
// Accumulate instantaneous speed
|
||||
speed_accumulator += speed;
|
||||
|
||||
if (!in_move_flag) {
|
||||
// If the platform is not moving, reset the speed
|
||||
speed_accumulator = speed_accumulator * SPEED_ZEROING_FACTOR;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Despite having various filters, due to the error, the speed may not "return" to 0, therefore, vibrations are also measured, and if they are less than the certain threshold, it is considered that the platform is at a standstill and the speed gradually resets to zero.
|
||||
|
||||
The complete code of the speedometer can be found in the Eitude repository on GitHub: https://github.com/XxOinvizioNxX/Eitude
|
||||
|
||||
### 6.4. Platform light sensor {#platform-light-sensor}
|
||||
|
||||
As our platform must work in various environmental conditions, and optical stabilization is very demanding on the visibility of the ArUco marker, it is important to have an automatic system for measuring the camera exposure by the level of illumination around it, and turning on additional illumination if there is a lack of lighting. In the long term, it is planned to use specialized sensors, for example, the BH1750, as light sensors.
|
||||
|
||||
In the current version of the prototype, 6 LEDs are used as a light sensor and an ADC built into the microcontroller. The stabilization algorithm (Liberty-Way) sends a request `L0` to the platform to check the illumination level. A message `S0 L <luminance>` is returned as a response.
|
||||
|
||||
|
||||
|
||||
Test for determining the level of illumination using LEDs (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/xQeiA945aRA" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
Exposure adjustment and adding additional illumination tests (clickable):
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/iMORim6zxsg" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
-----------
|
||||
|
||||
## 7. Conclusion {#conclusion}
|
||||
|
||||
At the moment, there is a debugged prototype of optical stabilization, GPS holding, altitude stabilization via barometer, different platform prototypes and a great amount of 3D models eager to be constructed.
|
||||
The project of the automatical landing of a drone onto a moving platform is not yet complete.
|
||||
|
||||
Follow the updates:
|
||||
|
||||
- In our repository GitHub: https://github.com/XxOinvizioNxX/Liberty-Way
|
||||
- On our YouTube channel: https://www.youtube.com/channel/UCqN12Jzy-1eJLkcA32R0jdg
|
||||
|
||||
In the future, we plan to do much more new and interesting stuff!
|
||||
|
||||
|
||||
128
docs/en/anticorona_drones.md
Normal file
128
docs/en/anticorona_drones.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# Drones to fight Corona
|
||||
|
||||
[CopterHack-2021](copterhack2021.md)
|
||||
|
||||
team: **Drones to fight Corona**
|
||||
|
||||
## Team
|
||||
|
||||
* Daria Miklashevskaya
|
||||
[d.miklashevskaya@innopolis.ru](mailto:d.miklashevskaya@innopolis.ru)
|
||||
* Yuriy Sukhorukov
|
||||
[y.suhorukov@innopolis.ru](mailto:y.suhorukov@innopolis.ru)
|
||||
|
||||
Innopolis University, B17-DS-II, B17-RO-I
|
||||
|
||||
## Introduction
|
||||
|
||||
The world faces the worst pandemic of XXI century, which affects lives and well-being of millions of citizens. To slow down the spread of the disease and give the healthcare system to react, people are obliged to wear masks, however, people sometimes ignore those rules, which puts lives of others under the threat.
|
||||
|
||||
There are laws in place to enforce mask wearing, but there is just not enough cops to monitor the situation in every mall, bus station etc and fine the law-breakers. We want to contribute to the solution of this problem, but instead of punishing people, we want to provide them with mask with our super-friendly and cute drone.
|
||||
|
||||
## Custom airframe
|
||||
|
||||
Since we do not have the Clover drone, we will use an airframe built and designed by us. Our system is designed to be platform-independent, so it can be installed on almost everything, even VTOL aircrafts.
|
||||
|
||||
The main idea is to use truss structure, because it works well against twisting and warping, besides, it can be assembled out of carbon tubes relatively easily.
|
||||
|
||||
<img src="../assets/anticorona/drone_frame.jpg" title="Frame">
|
||||
|
||||
The main advantage of such a system is that it distributes the impact between beams and effectively dissipates it. Engine mounts, however, are not impact-proof because they are specifically designed to break but save much more expensive and not-readily-available engines. This is why mounts are quickly-replaceable (only 3 screws) and made of cheap PLA plastic.
|
||||
|
||||
The space inside the central rhombus is occupied by the on-board equipment: batteries, PX4 flight controller, Jetson Xavier NX / AGX, power electronics, sensory equipment.
|
||||
|
||||
As it is shown on this picture, computers can be mounted on the bottom and completely protected by legs and the truss structure from any collision damage. Jetson AGX is marked with arrow. Almost invisible, isn't it?
|
||||
|
||||
<img src="../assets/anticorona/drone_with_jetson.jpg" title="AGX is safe">
|
||||
|
||||
All sensory equipment, like cameras, rangefinder, etc can be easily mounted on the beams with special bracket connectors. This type of connection provides flexibility because you can fine-tune camera angle or position before tightening screws and fixing it firmly in place, which is especially relevant for tracker-cameras.
|
||||
|
||||
We used one T-265 camera for visual odometry and one D-435 depth camera for both video input for neural net and for map-building (collision avoidance). T-265 suffers from "odometry drift" especially when engines are beat-up, which eventually happens after a number of crashes, so we have incorporated dampers to solve this problem.
|
||||
|
||||
<img src="../assets/anticorona/camera.jpg" title="Begone odometry drift" width=400 class="zoom center">
|
||||
|
||||
Finally, the drone with all equipment installed looks like this
|
||||
|
||||
<img src="../assets/anticorona/drone_assembled.jpg" title="Assembled drone" width=400 class="zoom center">
|
||||
|
||||
## Software
|
||||
|
||||
Thus far we discussed things which are specific to our custom airframe. Things we are going to discuss next are applicable for Clover drone as well. Our software is containerized so it can be launched on every platform that supports Docker, be it Windows machine, Linux machine, Jetson or Raspberry Pi.
|
||||
|
||||
We have split our drone software into two modules:
|
||||
|
||||
* Pipeline, which manages communication with ROS.
|
||||
* Neural net module, which talks with the pipeline via sockets.
|
||||
|
||||
The reason for this is simple - ROS supports only Python 2, and I do not feel like I'm building ROS with Python 3 because it is a bit troublesome. Our neural net, on the other hand, uses Pytorch which is Python 3 only, so the only way to run them both is to use inter-process communication of some sort.
|
||||
|
||||
Apart from compatibility issue, such an arrangement allows us to run inference module anywhere we want, e.g. on more powerful desktop PC or even somewhere in the cloud (google collab? Why not!).
|
||||
|
||||
This means that we can make our drone lighter by excluding heavy on-board computer and replacing it with something light like Raspberry Pi. Pipeline image is made as lightweight as possible, so it should be runnable even on really weak computers.
|
||||
|
||||
More detailed instructions on how to build and run our software are available in our [Gitlab repo](https://gitlab.com/k0t1k/thegreateye/-/tree/master).
|
||||
|
||||
## Neural net [^1]
|
||||
|
||||
We use 3rd version of YoLo neural network, pretrained on custom dataset for 50 epochs.
|
||||
|
||||
It runs 10-15 FPS on Jetson NX, which is enough for our task
|
||||
|
||||
## Exploration and collision avoidance
|
||||
|
||||
To make our drone useful and to operate it safely, we should somehow make the drone aware of its current position and surrounding objects. There are two ways we can solve this problem
|
||||
|
||||
* Use pre-built map as a ground truth and then calculate the position with e.g. Particle Filter
|
||||
* Build map on-the-fly, while avoiding collisions and moving towards the goal
|
||||
|
||||
The second approach is more robust, because it does not rely on any external map, which can be erroneous or just missing and hence we opted for it.
|
||||
|
||||
We use a path planner, described in [^2]. In this paper Receding
|
||||
Horizon Next-Best-View Planner is presented, which uses Rapidly-exploring Random trees to navigate and explore the environment. It yields the following results, here is the occupancy map and the corresponding tunnel as it is seen by human being:
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/anticorona/robot_view.jpg" title="Mask release manufactured" width=300 class="zoom center">
|
||||
<img src="../assets/anticorona/human_view.jpg" title="Mask release in cad" width=300 class="zoom center">
|
||||
</div>
|
||||
|
||||
The algorithm is lightweight, so even the small computer like Latte Panda can run it with high enough frequency, and since it is CPU-bound, it will not compete for resources with the neural net, which is almost entirely GPU-bound.
|
||||
|
||||
## Mask release
|
||||
|
||||
Detecting people without masks is cool, no doubt.
|
||||
|
||||
<img src="../assets/anticorona/masks.jpg" title="Master and his apprentice" width=400 class="zoom center">
|
||||
|
||||
But we want not only to detect them but to give him a mask as well, so, we have built this system that can give a mask to person.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/anticorona/release.jpg" title="Mask release in cad" width=300 class="zoom center">
|
||||
<img src="../assets/anticorona/release_Cad.jpg" title="Mask release manufactured" width=300 class="zoom center">
|
||||
</div>
|
||||
|
||||
This device looks like a regular firearm mag, and functions exactly in the same way. Masks can be loaded into containers made out of 20ml syringe barrels.
|
||||
|
||||
This device needs further engineering because current iterations are too fragile and unreliable, probably the best solution will be to use linear actuator and push the "casing" out of the action, like in actual firearm.
|
||||
|
||||
## 3D models
|
||||
|
||||
All the 3D models used to build this cute drone can be found in our [gdrive](https://drive.google.com/drive/folders/1tR5ePX24_i9tpllOPMcnZIUfse89c1YI?usp=sharing).
|
||||
|
||||
## Final thoughts
|
||||
|
||||
We all hope that Corona crisis will soon be over, and when it will be finally over, our drones will be still useful. We can deliver some small objects, like cosmetics or shaving blades to the customers' door, the task that currently is done by a human courier. This service (with shaving blades), when a guy comes and brings a new set of shaving blades every week is very popular in US and UK, so why not try to automate it.
|
||||
|
||||
This is an MVP, so some improvements are to be done. For example, payload refill and battery swaps are done manually for now, but this task should be automated. Actually, some work is already done in this direction:
|
||||
|
||||
<img src="../assets/anticorona/charging_drone.jpg" title="Mask release manufactured" width=300 class="zoom center">
|
||||
|
||||
Drone lands on a landing platform with special hooks which will connect to four metallic contacts (highlighted) and charge the battery. In future we want to change battery, not just charge it, but the mechanism is very complex and requires making custom batteries and battery mounts, also, it constraints placement of cameras, payload and so on.
|
||||
|
||||
For the general-purpose delivery drone, the working principle and hardware will remain the same, but software (neural net detector) will need an update.
|
||||
|
||||
Stay safe folks!
|
||||
|
||||
## References
|
||||
|
||||
[^1]: Massagué Respall, Victor & Devitt, Dmitry & Fedorenko, Roman. (2020). Unmanned Aerial Vehicle Path Planning for Exploration Mapping. 1-6. 10.1109/NIR50484.2020.9290232.
|
||||
[^2]: Nisarg Pethani & Harshal Vora. (2020) https://github.com/NisargPethani/Face-Mask-Detection-using-YOLO-v3
|
||||
@@ -1,5 +1,7 @@
|
||||
# Clover 4.2 assembly
|
||||
|
||||
Dimensional drawing – [clover-4.2.pdf](https://github.com/CopterExpress/clover/raw/master/docs/assets/dimensional-drawing/clover-4.2.pdf).
|
||||
|
||||
## Fasteners size
|
||||
|
||||
> **Hint** During assembly, screws and racks of various sizes are used, using fasteners of the wrong size can damage the copter.
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# Clover 4 assembly
|
||||
|
||||
Dimensional drawing – [clover-4.2-ws.pdf](https://github.com/CopterExpress/clover/raw/master/docs/assets/dimensional-drawing/clover-4.2-ws.pdf).
|
||||
|
||||
## Fasteners size
|
||||
|
||||
> **Hint** During assembly, screws and racks of various sizes are used, using fasteners of the wrong size can damage the copter.
|
||||
|
||||
24
docs/en/bennie.md
Normal file
24
docs/en/bennie.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Retail Drone - CopterHack 2021 article
|
||||
|
||||
CopterHack-2021, team: Bennie and the Jetson TX2.
|
||||
|
||||
My project is a drone that can scan a store shelf and determine if the representation of a specific brand is adequate for what the vendor paid for. In most retail stores, a brand will pay for space on a shelf in order to be more eye catching to the customer and eventually get more sales, which is why bigger brands are generally seen more. However because of either employee ineptitude or general non-compliance up to 15% of a brand’s space on a shelf that it paid for can be lost, which can lose the brand upwards of 5% loss in overall sales.
|
||||
|
||||
Several apps have been released to fight this such as Clobotics, however they all require an employee to go around manually and take snapshots. I wanted to build a system where a shop owner could simply place the drone at a starting point, click a button and have their inventory done automatically within minutes.
|
||||
|
||||
Since all inventory in a shop is usually on the shelves and I wanted to not have the drone rely on GPS I fitted the Clover’s Pi camera in front for object detection and navigation. Rather than using map-based navigation since one can’t expect a shop owner to place markers perfectly on the ground, opencv2 has a built in ArUco marker detection method that identifies and draws a bounding box around all markers in frame. So once the drone takes off from the starting position, it identifies where the marker is in frame and uses the Clover’s `navigate()` method to center the marker and its area to place the Clover approximately 1 metre from it.
|
||||
|
||||
What’s expected is that the shop owner places markers at every different brand’s section in ascending order down an aisle. The drone has a specific marker ID it’s looking for and once it’s centered itself on the nearest marker, it determines its ID and moves either left or right depending if the identified marker is lower or higher than the target. This way the Clover moves down an aisle stopping at each marker until it reaches the target.
|
||||
|
||||
In order to identify the number of items of each brand, I’ve trained a TensorFlow model and stored its metadata in a caffemodel file for the Python script to pull from. Every time the drone stops at a marker, a method is run that applies a convolutional neural net to the frame and determines how much of a specific item (right now the model is trained to recognize soda cans but can easily be taught other items) it at said marker (remember that each marker is to be placed at each brand’s individual section). In the video below, you’ll see a POV video of my drone with two markers placed on the wall in my garage. What happens is that the drone takes off, centers itself on the first marker and as its ID is 140 and the target ID is 138, it’s driven left to the second marker which has a soda can hung next to it. It then identifies the soda can, conveying the number of cans of that brand to the shop owner before centering itself on the marker and landing due to it reaching the target marker.
|
||||
|
||||
My main goal with this project was accessibility. I wanted to make a drone that could navigate purely based on its camera with computer vision tools that aren’t exclusive to MAVLink or ROS drones. By fitting the camera to the front not only would a user be able to get more functionality out if it than simply map-based navigation but would be able to make more useful applications such as shop keeping or security through facial recognition. With alterations to the left, right, front, back, up and down commands this script can be applied to any hackable drone and requires little to no prior experience to use.
|
||||
|
||||
Check out the video below to see it in action:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/jsVY0DM9Sew" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
## Contact info
|
||||
|
||||
* Email - [jadenbh12@gmail.com](mailto:jadenbh12@gmail.com)
|
||||
* Telegram - [@jadenbh12](tg://resolve?domain=jadenbh12)
|
||||
@@ -14,7 +14,7 @@ For correct work of the blocks programming, `blocks` argument in the Clover laun
|
||||
|
||||
## Running
|
||||
|
||||
To run Clover's blocks programming interface, [connect to Clover's Wi-Fi](wifi.md) and go to web-page http://192.168.11.1:8080/clover_blocks/ or click the link *Blocks programming* at the [main page](wifi.md#web-interface).
|
||||
To run Clover's blocks programming interface, [connect to Clover's Wi-Fi](wifi.md) and go to web-page http://192.168.11.1/clover_blocks/ or click the link *Blocks programming* at the [main page](wifi.md#web-interface).
|
||||
|
||||
The page looks as follows:
|
||||
|
||||
|
||||
37
docs/en/blue_jay_eindhoven.md
Normal file
37
docs/en/blue_jay_eindhoven.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Designing a drone and a path planning algorithm
|
||||
|
||||
[CopterHack-2021](copterhack2021.md), team: **Blue Jay Eindhoven**.
|
||||
|
||||
## Introduction
|
||||
|
||||
We at Blue Jay Eindhoven are a student team of the Eindhoven University of Technology. We are doing research on drones that fly indoors, are interactive, autonomous, safe and helpful.
|
||||
|
||||
We are participating in the Copterhack 2021, because COEX has a lot of knowledge about making a drone. With the help of COEX's expertise, we would be able to develop our drone further. However, the project with which we started the Copterhack turned out to be not that successful. We therefore also didn't get to have a more in depth discussion with COEX. The fact that we are not an open source company, added to this. We couldn't just share everything and when that one project failed, we first had to look at what we are going to share next. Because of these events, the collaboration part hasn't really lifted off.
|
||||
|
||||
The information that you are going to find in this project summary is therefore not that specific developed for the Clover drone. It can however certainly be used to customize the Clover drone. In addition, it can also give a first overview for beginners on how to design a path planning algorithm and how the design process of a drone looks like.
|
||||
|
||||
We are still planning on doing some research on the Clover drone itself. This will mainly be on the stability and movability of the our drone. But we are going to start with investigating it on the Clover drone. So there might be a nice further collaboration on this. In addition, we are also trying to implement the codes for the Clover drone onto our drones. By doing this, we will also be able to provide some feedback on it and develop it further.
|
||||
|
||||
Now we will give you a short summary of our results on the Path Planning Algorithm and the Hardware Research that we have done. For the full reports, you can go to this google drive: https://drive.google.com/drive/folders/1vfWjWD5Qx38mDta0PvMFvAv6jC-mxF7U?usp=sharing.
|
||||
|
||||
## Path Planning Algorithm
|
||||
|
||||
It is investigated what the most optimal path planning algorithm is for the Clover drone. This is done since it was noted that this is not done in the base version of the drone. The path planning algorithm makes it possible that the drone flies autonomous in a much better way than without the algorithm.
|
||||
|
||||
In the documentation, we have set up a plan to put this path planning algorithm to work on your drone. This is a low level algorithm, so everyone should be able to implement it. The algorithm does however need some sort of map from which it can get information on the possible paths. So that part, you still have to implement yourselves.
|
||||
|
||||
## Hardware Research
|
||||
|
||||
The report describes the internship project carried out at Blue Jay. As we focus on indoor drone application, we wishes to minimize the produced noise to improve user experiences. On the other hand, we also wish to improve the flying efficiency for benefiting flying time. As result, the project is about making the drone more efficient with less noise emitted during the operation. For producing design to approach the problem, design methodology has been applied. In the end the ducted fan design has been chosen through studied theory and experimenting. However, there are two additional requirements, an increase in amounts of sensors and an increase in propeller numbers to increase safety. These additional requirements result the drone has less flying time due to the increase in weight. However, the selected design still improved the efficiency of selected propeller.
|
||||
|
||||
This hardware part is more of a general research that can be applied to all drones, including the Clover drone. If a group of high school or university students would like to do their own research on the Clover drone, they can use the research for ideas. They can for instance perform a project in which they design their own 3D printed ducted fans to use on the Clover drone. The research in the report would then be a good first read on how to design such a thing and what the performance results could be.
|
||||
|
||||
In addition, the kind of propellers that are used on the Clover drone can also be adjusted. Maybe a group wants get a little smaller or larger propellers or even a different shape. The research done can then also help as a guide to decide what kind would be best for that specific use with respect to size and shape.
|
||||
|
||||
It is also useful when one wants to use the code that the Clover drone uses, but also wants to develop their own drone. The hardware research can then be used as a guide on how you can do this. It states all kind of factors that should be taken into account and in what way you can do this.
|
||||
|
||||
## Full Project Information
|
||||
|
||||
To see what our project at Blue Jay is all about, you can watch the following video of our interim event: [https://www.youtube.com/watch?v=E\_8TTQN92pU&t=0s](https://www.youtube.com/watch?v=E_8TTQN92pU&t=0s). We state our user case, explain what we have achieved so far and what the plans are for the future.
|
||||
|
||||
If you have questions or ideas, feel free to ask! You can contact us at [info@bluejayeindhoven.nl](mailto:info@bluejayeindhoven.nl).
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
In order to perform the sensor calibration, select the *Vehicle Setup* tab and choose the *Sensors* menu.
|
||||
|
||||
> **Caution** If you use the flight controller *COEX Pix*, all *Autopilot Orientation* columns must specify `ROTATION_ROLL_180_YAW_90`, otherwise the flight controller will not correctly perceive the tilt and rotation of the copter.
|
||||
> **Caution** If you use the flight controller [*COEX Pix*](coex_pix.md), all *Autopilot Orientation* columns must specify `ROTATION_ROLL_180_YAW_90`, otherwise the flight controller will not correctly perceive the tilt and rotation of the copter.
|
||||
|
||||
## Compass
|
||||
|
||||
|
||||
13
docs/en/coex_gps.md
Normal file
13
docs/en/coex_gps.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# COEX GPS
|
||||
|
||||
The GNSS receiver **COEX GPS** is compatible with the [COEX Pix](coex_pix.md) flight controller. This receiver comes with a COEX Clover Drone Kit.
|
||||
|
||||
## Port pinouts
|
||||
|
||||
### Top view
|
||||
|
||||
<img src="../assets/coex_gps/coex-gps-top.png" width=400 class=zoom>
|
||||
|
||||
### Bottom view
|
||||
|
||||
<img src="../assets/coex_gps/coex-gps-bottom.png" width=400 class=zoom>
|
||||
15
docs/en/coex_pdb.md
Normal file
15
docs/en/coex_pdb.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# COEX PDB
|
||||
|
||||
**COEX PDB** is the power distribution board used in [Clover 4 Drone kit](assemble_4_2.md).
|
||||
|
||||
Board size: 35x35 mm.
|
||||
|
||||
## Port pinouts
|
||||
|
||||
### Top view
|
||||
|
||||
<img src="../assets/coex_pdb/coex-pdb-top.png" width=400 class=zoom>
|
||||
|
||||
### Bottom view
|
||||
|
||||
<img src="../assets/coex_pdb/coex-pdb-bottom.png" width=400 class=zoom>
|
||||
@@ -35,9 +35,9 @@ The **COEX Pix** flight controller is a modified [Pixracer](https://docs.px4.io/
|
||||
|
||||
### Port pinouts
|
||||
|
||||
<img src="../assets/coexpix-top.jpg" width="400" class="zoom">
|
||||
<img src="../assets/coex_pix/coexpix-top.jpg" width="400" class="zoom">
|
||||
|
||||
<img src="../assets/coexpix-bottom.jpg" width="400" class="zoom">
|
||||
<img src="../assets/coex_pix/coexpix-bottom.jpg" width="400" class="zoom">
|
||||
|
||||
> **Note** On rev. 1.0 boards *RC IN* port and microSD slot are switched. Pinout for the *RC IN* port is the same on these boards.
|
||||
|
||||
@@ -70,6 +70,6 @@ The board utilizes low-noise DC-DC converters, voltage inputs have LC and ferrit
|
||||
|
||||
### Port pinouts
|
||||
|
||||
<img src="../assets/coex_pix/coexpix-top-rev1.2.jpg" width=400 class=zoom>
|
||||
<img src="../assets/coex_pix/coexpix-top-rev1.2.png" width=400 class=zoom>
|
||||
|
||||
<img src="../assets/coex_pix/coexpix-bottom-rev1.2.jpg" width=400 class=zoom>
|
||||
<img src="../assets/coex_pix/coexpix-bottom-rev1.2.png" width=400 class=zoom>
|
||||
|
||||
@@ -56,7 +56,7 @@ Prepare your article and send it as a pull request to the [Clover repository](ht
|
||||
git checkout -b new-article
|
||||
```
|
||||
|
||||
4. Write a new article in the [Markdown](https://en.wikipedia.org/wiki/Markdown) format and save it in the `docs/ru` or `docs/en` folder (for example, `docs/en/new_article.md`).
|
||||
4. Write a new article in the [Markdown](https://en.wikipedia.org/wiki/Markdown) format and save it in the `docs/ru` or `docs/en` folder (for example, `docs/en/new_article.md`). Don't forget to give you contacts (e-mail / Telegram / ...) in articles on your projects.
|
||||
5. Place additional visual assets in the `docs/assets` folder and add them to your article.
|
||||
6. Add a link to your article to the appropriate section in the `SUMMARY.md` file (in the same folder as in the fourth step):
|
||||
|
||||
|
||||
35
docs/en/copterhack2021.md
Normal file
35
docs/en/copterhack2021.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# CopterHack 2021
|
||||
|
||||
CopterHack 2021 is a team competition for the development of open source projects for the Clover quadcopter platform.
|
||||
|
||||
All information about the event can be found on the official website: https://coex.tech/copterhack.
|
||||
|
||||
Full stream of the final: https://www.youtube.com/watch?v=Z06vxuAHmuE.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/copterhack2021/1.jpg" class="zoom border">
|
||||
<img src="../assets/copterhack2021/2.jpg" class="zoom border">
|
||||
</div>
|
||||
|
||||
## Participating teams articles
|
||||
|
||||
|Place|Team|Project|Points|
|
||||
|-|-|-|-|
|
||||
|1|🇧🇾 FTL|[AdvancedClover](../ru/advanced_clover.html)|18.8|
|
||||
|2|🇷🇺 EasyToFly|[EasyToFly](../ru/easytofly.html)|18.5|
|
||||
|3|🇩🇪 ADDI|[3D-printed generative design frame](generative_design_frame.md)|17.8|
|
||||
|4|🇰🇬 AT Makers|[D-drone Graffiti-copter](ddrone.md)|16.7|
|
||||
|5|🇶🇦 DroMap|[The Indoor Mapping Drone](dromap.md)|16.5|
|
||||
|6|🇰🇬 MINIONS|[Seed spreading quadcopter](seeding_drone.md)|15.5|
|
||||
|7|🇷🇺 Hardaton|[Хардатон Квиддич](../ru/hardaton_quidditch.html)|15.48|
|
||||
|8|🇷🇺 Atomic Ferrets|[Система засечки для дронов](../ru/race_timing_sys_copterhack.html)|15|
|
||||
|9|🇷🇺 Drones to fight Corona|[Drones to fight Corona](anticorona_drones.md)|14.6|
|
||||
|10|🇷🇺 AMLS|[Autonomous Multirotor Landing System](amls.md)|12.8|
|
||||
|11|🇷🇺 PаD30DЖ|[Октокоптер со специфичным расположением пропеллеров](../ru/oktazodg.html)|11.6|
|
||||
|12|🇷🇺 Zaural Viking|[Программируемый летающий автомобиль](../ru/zaural_viking.html)|11.4|
|
||||
|13|🇨🇦 Bennie and the Jetson TX2|[Retail Drone](bennie.md)|9.8|
|
||||
|14|🇳🇱 Blue Jay Eindhoven|[Designing a drone and a path planning algorithm](blue_jay_eindhoven.md)|9.6|
|
||||
|15|🇷🇺 ProCleVeR|[Разработка системы для управления БПЛА с помощью шлема виртуальной реальности](../ru/remote-control-with-oculusvr.html)|8.5|
|
||||
|16|🇷🇺 Quadrotor|[Дрон-Агроном](../ru/drone-agronom.html)|7.7|
|
||||
|
||||
See points by criteria in the [full table](https://docs.google.com/spreadsheets/d/1L9NDrw4c4vTCIVR3aC8ErAjxnuBg-Afil9AwUQZVJ5I/edit?usp=sharing).
|
||||
98
docs/en/ddrone.md
Normal file
98
docs/en/ddrone.md
Normal file
@@ -0,0 +1,98 @@
|
||||
# D-drone Copter Hack 2021 by AT Makers
|
||||
|
||||
[CopterHack-2021](copterhack2021.md), team **AT Makers**.
|
||||
|
||||
<img class="center" src="../assets/ddrone/final.gif" width="600">
|
||||
|
||||
## Intro
|
||||
|
||||
People strive to teach artificial intelligence everything they can do themselves. We are taught to draw from childhood. And why not teach the drone to draw? At the moment, copters and graffiti are gaining popularity. So we decided to combine them.
|
||||
|
||||
## Models and assembly
|
||||
|
||||
<img class="center" src="../assets/ddrone/full_holder.png" width="300" class="zoom">
|
||||
|
||||
<img class="center" src="../assets/ddrone/full_holder_in_real.jpg" width="300" class="zoom">
|
||||
|
||||
To complete the project you need to have in stock:
|
||||
|
||||
- spray paint
|
||||
- clover 4 kit
|
||||
- servo MG90S
|
||||
- 3D printer
|
||||
- spray can extension straw
|
||||
- velcro
|
||||
- 4 long screws and nuts M4 or M3
|
||||
- 2-4 short self-tapping screws M4 or M3.
|
||||
|
||||
[Download](https://github.com/PerizatKurmanbaeva/D-drone/tree/master/details) and 3D-print details:
|
||||
|
||||
- holder
|
||||
- screw
|
||||
- rack_holder_with_nut
|
||||
- rack x2
|
||||
- servo_holder.
|
||||
|
||||
**Spray holder.** The spray holder is attached to the deck with 4 screws and nuts. To fasten the can to the holder, we used a tape with velcro. With 4 nuts and screws, we fix the drone's upper deck with spray holder.
|
||||
|
||||
Holder weight: 90g.
|
||||
|
||||
<img class="center" src="../assets/ddrone/holder.png" width="300">
|
||||
|
||||
If the diameter of the can is less than the diameter of the holder, we use the part in the form of an arc, with the size of the difference between them. This helps us to fix the spray can firmly.
|
||||
|
||||
**Pressing mechanism.** To push the valve, we will use a screw drive with a fixed nut. A bar with holes will be attached to the servo, which will include the racks attached to the nut. This helps the servo to move only on one axis, up and down. We also modeled the cap for the spray can button, since the surface of the nozzle is uneven.
|
||||
|
||||
<img class="center" src="../assets/ddrone/pressing_mechanism.png" width="300" class="zoom">
|
||||
|
||||
<img class="center" src="../assets/ddrone/pressing_mechanism_in_real.jpg" width="300" class="zoom">
|
||||
|
||||
## Before launching
|
||||
|
||||
### Configuring the servo scripts
|
||||
|
||||
Before starting the copter, you need to download [servo.py](https://github.com/PerizatKurmanbaeva/D-drone/blob/master/examples/servo.py) and move it to RPi. You can simply copy and paste using the clipboard. Or copy it using the scp command. For instance:
|
||||
|
||||
```bash
|
||||
scp servo.py pi@192.168.11.1:/home/pi
|
||||
```
|
||||
|
||||
Then run the following commands remotely on the Raspberry Pi:
|
||||
|
||||
```bash
|
||||
sudo pigpiod
|
||||
python servo.py
|
||||
```
|
||||
|
||||
### Configuring the Web interface
|
||||
|
||||
Download this [repository](https://github.com/PerizatKurmanbaeva/visual_ddrone) in .zip format. Copy to RPi and unpack using the following commands:
|
||||
|
||||
```bash
|
||||
scp visual_ddrone-master.zip pi@192.168.11.1:/home/pi
|
||||
cd catkin_ws/src/clover/clover/www
|
||||
unzip /home/pi/visual_ddrone-master.zip .
|
||||
mv visual_ddrone-master ddrone
|
||||
```
|
||||
|
||||
Now to open the web interface, click on the link [http://192.168.11.1/clover/drone](http://192.168.11.1/clover/drone).
|
||||
|
||||
## Web interface
|
||||
|
||||
Our drone is launched via [website](https://perizatkurmanbaeva.github.io/visual_ddrone). The web interface allows you to draw and encode what you draw in G-code. The coordinate data will be transmitted for further processing and execution by the copter.
|
||||
|
||||
<img class="center" src="../assets/ddrone/screen_2.png" width="600" class="zoom">
|
||||
|
||||
We pick the web interface to control the copter because it is easier for the user.
|
||||
|
||||
<img class="center" src="../assets/ddrone/instruction.png" width="300" class="zoom">
|
||||
|
||||
## Flights
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/ErtioCj5iMw" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
## Special Thanks
|
||||
|
||||
Project was created with financial support of International Ala-Too University.
|
||||
|
||||
|
||||
238
docs/en/dromap.md
Normal file
238
docs/en/dromap.md
Normal file
@@ -0,0 +1,238 @@
|
||||
# DroMap: The Indoor Mapping Drone
|
||||
|
||||
[CopterHack-2021](copterhack2021.md), team: **DroMap**. E-mail: [officialdromap@gmail.com](mailto:officialdromap@gmail.com).
|
||||
|
||||
Team:
|
||||
|
||||
* Shouq AlQahtani
|
||||
* Ameena AlMansouri
|
||||
* Noof AlMarri
|
||||
|
||||
## Abstract
|
||||
|
||||
In the modern era, the world is witnessing a magnificent development in the field of architecture and interior design. Due to architectural development, the current measuring tools such as metal tapes and leaser meters became insufficient for assisting both architects and interior designers in taking the measurements for buildings and facilities. Because the accuracy of obtained readings depends on the professionalism of the users and the nature of these tools is unidirectional, the measurement taking process becomes less efficient in terms of time and labor. Since drones have played an essential role in revolutionizing the world of science and automation due to their use in a huge number of daily life applications, an introduction of indoor drones in the field of mapping and architecture is indispensable. Hence, the DroMap project proposes an autonomous indoor drone that can navigate autonomously and create a map of the indoor environment along the way. For the aforementioned purpose, a LiDAR sensor is used to collect data of the indoor place which is sent to a host computer. Afterward, simultaneous localization and mapping algorithm utilizes these data to pave the way for creating a 2-dimensional map. This autonomous indoor mapping drone system is not prone to inefficiency and human errors like in manual mapping and has the potential to take indoor mapping to the next level in the near future.
|
||||
|
||||
## Motivation
|
||||
|
||||
### Problem Statement
|
||||
|
||||
Architects lives are constantly in danger due to the nature of their work as they are supposed to enter buildings without knowing their structure, these dangers could potentially threaten their lives and can lead to many issues. According to [^1], there are 1.2 deaths per 100,000 architects and that job is ranked 19th among the most dangerous jobs in the United States. One example of a fatal accident is the accident of Bruno Travalja which happened in 2016, this architect fell from the 48th floor of a building while taking measurements. In addition to being dangerous, the process of mapping an indoor environment is time-consuming, especially in transferring the raw measurements into a 2-dimensional map [^2]. Therefore, the need for robot assistance in mapping and measurement taking processes reaches the peak. Autonomous indoor mapping using drones or robots is considered an important tool where the drone can reach different places which are inaccessible to humans due to space constraints or security reasons [^3].
|
||||
|
||||
The use of robots has increased dramatically within the past decade due to their enormous potential in both civil and architectural applications. Specifically, in designing and building robots for mapping enclosed buildings. Even though most of the works were implemented on unmanned ground vehicles (UGV), the current experimental use of unmanned Ground vehicles for indoor mapping suffers from a few shortcomings. Particularly, most implementations suffer from low performance regarding time consumption and have difficulty accessing narrow places. Since UGVs have limitations in terms of time consumption and navigation rigidity, in the DroMap project we decided to use drones as a replacement for UGVs to map indoor sites. This is because drones are unique in their ability to traverse any 3D interior space without any restrictive concerns regarding space architecture. Additionally, since these vehicles are not required to remain on the ground, aerial vehicles can fully explore the extent of the indoor space, regardless of their interiors. Furthermore, unmanned aerial vehicles can access difficult to reach areas.
|
||||
|
||||
A questionnaire was conducted for this project to study the need for an indoor mapping drone which involved 72 architects and interior designers. The following question was asked to have an estimate of the time taken by the targeted category for taking the measurements of a large building. According to the survey results, 61% of the sample consume more than 60 minutes to measure a large building. This shows that the measurement taking process is time-consuming.
|
||||
|
||||
|
||||
|
||||
#### Technical Challenges
|
||||
|
||||
* The positioning system calculates the odometry data based on the laser scanner poses. This might misestimate the drone’s position with respect to the surroundings.
|
||||
* The LiDAR readings could be infinite if the distance between the LiDAR and the surrounding walls exceeds the LiDAR range.
|
||||
* The communication between the Raspberry Pi and the PC relies heavily on Wi-Fi. Therefore, any loss in the Wi-Fi signal would terminate the communication between the drone and PC.
|
||||
|
||||
#### Non-technical Challenges
|
||||
|
||||
<!-- markdownlint-disable MD044 -->
|
||||
|
||||
* The indoor environment could be full of obstacles, which impedes path planning process.
|
||||
* The mirrors, windows, and glass doors may affect the accuracy of the map as they are not detected correctly by the laser pulses.
|
||||
|
||||
<!-- markdownlint-disable MD044 -->
|
||||
|
||||
### Project Significance
|
||||
|
||||
Measuring a room or a full building along with transforming the collected data to a full map is time-consuming and requires massive effort. DroMap helps architects and interior designers to measure and generate a fully constructed 2D map with less time and effort. To help us understand the problem better, we conducted a survey to assess the need for an indoor mapping drone. This project will provide a great advantage for architects and interior designers as it would save time and effort in the map construction process. In addition, it will assure great cooperation from both the computer and architecture fields.
|
||||
|
||||
Generally, the process of mapping an indoor environment is composed of two phases; the first phase is the measurement taking phase and the second phase is the map drawing phase. However, the project introduces another way to create a map that is faster and requires less effort; as the measurements of the surroundings will be taken by the system once it is activated and processed by Simultaneous Localization and Mapping algorithms (SLAM) for building and updating maps as well as positions of an unknown environment in robotics in real-time. According to the survey, 94% of the sample agreed that it would be useful to have a robotic based measuring tool. Therefore, the proposed solution will successfully assist architects and interior designers in mapping indoor areas.
|
||||
|
||||
|
||||
|
||||
Based on the conducted survey, accuracy is the most important characteristic to be satisfied with the project. The below figure demonstrates that 48 of the sample sizes care about having high accuracy. Moreover, the second most important feature to be reached is having a short scanning time, which highlights the importance of the project.
|
||||
|
||||
|
||||
|
||||
Furthermore, since the project employs multiple concepts related to indoor robots and indoor data processing, it can be extended to assist other fields in Qatar rather than the architecture field only. For example, this project could be a great step towards training drones to handle different tasks related to search and rescue such as entering buildings on fire or finding a missing person in indoor places. This will serve to develop more technologies to process the indoor data in various environments and conditions, also to develop drones that are capable to operate in indoor areas with different functionalities.
|
||||
|
||||
## Proposed solution
|
||||
|
||||
DroMap project consists mainly of two major components: the drone and the drone add-on. The drone is responsible for the physical movement of the entire system. The drone add-ons consist of necessary sensors for mapping, path planning, and mounting equipment such as Raspberry Pi 4, RPLiDAR A1M8, Sonar, and range finder. The Raspberry Pi collects the data from the sensors. While the data is being collected by the Raspberry Pi, the Hector SLAM will process these data in real-time to formulate 2-dimensional maps. After that, the map will be sent wirelessly to a remote PC and visualized through RVIZ software tool.
|
||||
|
||||
|
||||
|
||||
### Hardware/software to be used
|
||||
|
||||
#### Hardware selection
|
||||
|
||||
##### COEX Clover Drone kit
|
||||
|
||||
Clover is a complete STEM educational programmable drone kit which includes unassembled quadcopter with four propellers and open-source software.
|
||||
|
||||
* Limitless possibilities of a fully programmable drone (Open Source).
|
||||
* Drone can operate stably without GPS.
|
||||
* The Clover platform exploits the ROS framework.
|
||||
* Made especially for Indoor flights.
|
||||
|
||||
##### Slamtec RPLiDAR A1M8
|
||||
|
||||
LiDAR is low cost 2D 360° 12m scanning sensor.
|
||||
|
||||
* Omnidirectional Laser Range Scanner 360°.
|
||||
* Compatible with ROS.
|
||||
* Very high sampling Rate 8k times, Considered as one of the Highest in the Current LiDAR industry.
|
||||
* Ideal for indoor Navigation and Localization using UAVS.
|
||||
|
||||
##### Raspberry Pi 4 Model B
|
||||
|
||||
Raspberry Pi is a single-board computer which is used as a companion computer.
|
||||
|
||||
* Low energy consumption.
|
||||
* Connect the drone over Wi-Fi.
|
||||
* Responsible for flight autonomy.
|
||||
* Access and issue commands to peripherals.
|
||||
|
||||
##### VL53L1X RangeFinder Sensor
|
||||
|
||||
Laser Ranging Sensor Module Rangefinder. One of the smallest time-of-flight 940 nm laser VCSEL. Measuring absolute range up to 4 meters.
|
||||
|
||||
* The Range Finder Optical Ranging sensor is an integrated sensor with embedded infrared, eye-safe laser, advanced filters and high-speed photon detection arrays.
|
||||
* Range finder Supports 400cm sensing range, suitable for many applications.
|
||||
|
||||
#### Software selection
|
||||
|
||||
##### Robot Operating System (ROS)
|
||||
|
||||
A framework which runs on Linux operating system, and will be used as a firmware to control and monitor the system.
|
||||
|
||||
##### COEX Virtual Machine
|
||||
|
||||
A Linux operating system that has a pre-installed ROS along with some necessary dependencies and packages in addition to a pre-configured Gazebo environment.
|
||||
|
||||
##### Gazebo
|
||||
|
||||
The simulation tool that will be used to test and try different mapping and automation approaches.
|
||||
|
||||
##### Visual Studio Code
|
||||
|
||||
A text editor to write python scripts to program the drone.
|
||||
|
||||
##### RVIZ
|
||||
|
||||
A visualization tool to visualize the LiDAR readings.
|
||||
|
||||
##### QGroundControl
|
||||
|
||||
QGroundControl supports full flight control and mission planning for any MAVLink enabled drone.
|
||||
|
||||
## Implementation
|
||||
|
||||
The implementation divided into two parts. The first part is to work on the simulation software, and the second part is to work on the physical hardware components. The simulation software helped us to have an estimation of how the system will work in the physical world. Through the simulation software, we were able to identify some implementation challenges and finding solutions for them. In addition, the simulation software gave us the opportunity to process the sensors data and test the sensors before testing them physically, which speeded up the process of working on the physical components and testing them. Moreover, it was found that the results obtained from the simulated components and the physical components were close to each other. In this section, we demonstrate the progress that happened in both the physical and the virtual worlds.
|
||||
|
||||
### The Simulation Software
|
||||
|
||||
#### The Mapping algorithm
|
||||
|
||||
The Hector SLAM algorithm was selected in this project due to its high efficiency in mapping indoor environments, its ability to work with drones efficiently, and its facility to be integrated with the selected LiDAR sensor. Moreover, it consumes less power in handling some cases where the indoor environment is dynamic, and the obstacles are moving [^4]. Hector SLAM is an algorithm that is used widely in mapping unknown indoor environments. The algorithm is LiDAR-based, and it uses the Gaussian Newton equation to construct accurate maps from the laser scanner data [^5]. Moreover, this algorithm does not use any odometry data to estimate the robot’s position with respect to its surroundings. Instead, the algorithm utilizes the difference in the laser scanner locations to calculate the odometry [^6]. This feature qualifies the Hector SLAM algorithm to work optimally with the unmanned aerial vehicles given that in most of the cases, the odometry data is calculated from processing the wheels motion and that is not the case with UAVs. In addition, the algorithm provides an accurate estimation of the robot’s position with respect to its surroundings.
|
||||
|
||||
#### The Exploration Algorithm
|
||||
|
||||
The method used in this project to explore the indoor sites is selected to be the wall following algorithm due to its effectiveness and simplicity. The implementation of that algorithm can be summarized into three main functions which are: `left_side()` , `move_forward()`, and `take_stop_action()` which are represented in a while loop as following:
|
||||
|
||||
> **Note** The implementation of the wall following algorithm highly depends on the LiDAR used in the simulator which is Hokuyo laser scanner with 360 rotation angle and 720 readings per 32ms. However, the physical LiDAR used is RPLiDAR A1M8 which provides 360 readings per rotation.
|
||||
|
||||
```python
|
||||
while(1):
|
||||
left_side()
|
||||
move_forward()
|
||||
take_stop_action()
|
||||
```
|
||||
|
||||
```python
|
||||
left_side()
|
||||
```
|
||||
|
||||
This function uses the LiDAR readings that are pointing exactly to the west of the drone, it measures how far the drone is from the left wall, then adjust the drone to it such that the drone is approximately 0.7 m away from the left wall. The reason of using 0.7 meters is because the drone has higher error that expected. Therefore, a while loop is used to ensure that the drone is far enough from the wall.
|
||||
|
||||
```python
|
||||
move_forward()
|
||||
```
|
||||
|
||||
This function was implemented to safely move the drone forward without hitting a wall, or without skipping an outer corner. The logic behind this algorithm is that it uses the concept of the right angle, and multiple readings which correspond to different angles to measure the safe distances. The bellow flow chat demonstrates the logic of that algorithm in details.
|
||||
|
||||
<img src="../assets/dromap/algorth_logic.png" height=600 class="center zoom">
|
||||
|
||||
When the function ends, the drone will either stop after an inner corner, or an outer corner.
|
||||
|
||||
```python
|
||||
take_stop_action()
|
||||
```
|
||||
|
||||
This function handles two different situations:
|
||||
|
||||
* The first situation is that the drone may stop when it faces an inner corner, this can be detected by measuring the distance from the front wall, then compare the current distance of the left LiDAR reading with the previously recorded one, if the comparison showed that there is a small difference between these two readings, then this means that the drone must rotate to the right and continue its path.
|
||||
* The second situation is that the drone may stop when it detects an outer corner, the logic is exactly like the first situation except, that the drone must be away from the front wall (with distance greater than 1.5 meter). In addition, the difference between the current left LiDAR reading, and the previously recorded reading must be greater than 0.5 m. If this is the case, then the drone has stopped because of an outer corner. Therefore, the drone must rotate to the left and continue its path.
|
||||
|
||||
The following video illustrates a ROS Simulation test on Wall Following Algorithm:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/HgLHC0D76f8" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
#### Testing
|
||||
|
||||
|
||||
|
||||
The above figure demonstrates the drone exploring a maze autonomously while constructing a 2D map in real-time. The terminal shows the safe distances to move forward, these distancing where calculated using the aforementioned flowchart.
|
||||
|
||||
The following figures show a constructed 2D map of different environments.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following video demonstrates an autonomous maze exploration with Hector SLAM responsible for constructing a 2D map:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/fxshlaoCnEc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### The physical hardware
|
||||
|
||||
This section illustrates the progress done regarding the hardware components. The first step done was to establish a Wi-Fi communication between the Raspberry Pi and the remote PC. The second step was to install the hector SLAM and robot Localization packages in the Raspberry Pi to visualize the maps remotely.
|
||||
|
||||
#### Initial Setup
|
||||
|
||||
The drone is assembled and configured correctly to accomplish the autonomous mapping mission. The RPliDAR A1M8 and all other necessary sensors are mounted on the drone as shown in the figure bellow.
|
||||
|
||||
<img src="../assets/dromap/3.jpeg" width=400 class="center zoom">
|
||||
|
||||
To set up the drone ready for mapping, the raspberry pi image created by COEX was installed on the micro-SD card. COEX Raspberry Pi image, COEX pixracer image and COEX virtual machine were selected as they contain all the necessary tools and packages to work efficiently with clover platform. The installed platform is based on Raspbian operating system and ROS. After flashing the image on the SD, the next step is to connect clover to Wi-Fi.
|
||||
|
||||
#### Network Setup
|
||||
|
||||
The drone produces a map of an unknown indoor environment by sending data received from the sensors to a remote pc. The transmission takes place over a wireless channel to get a map in real-time. One of the essentials for DroMap is to setup the connection between the drone and the remote PC. In DroMap Project ROS network must satisfy the listed below requirements:
|
||||
|
||||
1. There must be a full bidirectional communication between all the nodes.
|
||||
2. Every component in the network must advertise its name.
|
||||
3. In ROS network one of the components must be declared as the ROS master. Specifically, the ROS master is the drone (Clover-6064).
|
||||
4. All ROS packages needed in the project, must use the ROS master.
|
||||
|
||||
All these requirements are fulfilled in our design.
|
||||
|
||||
#### Required packages
|
||||
|
||||
After the installation of ROS, the drone was ready to install RPLidar ROS package and Hector SLAM. These packages are installed by cloning them in a catkin workspace src folder. Then build them by running catkin build. The following commands were entered in the terminal show the process of installing RPLidar package and hector SLAM in raspberry pi. The `rplidar_ros` package is responsible for retrieving the RPLidar data and hector SLAM package is responsible for building maps. `rplidar_ros` and `hector_slam` packages ware installed from GitHub.
|
||||
|
||||
#### Testing
|
||||
|
||||
The testing phase was divided into several stages in order to test the sensor and the SLAM algorithm in several closed places. This makes it possible to identify obstacles and risks that may face us in the future.
|
||||
|
||||
We did several of the following elementary tests:
|
||||
|
||||
* Firstly, we flew the drone to obtain maps using Hector Mapping with the remote control.
|
||||
* Secondly, we have moved to the automation stage of implementing the codes applied in the simulator.
|
||||
* Finally, From here we did some tests, for example, the drone flies to the wall, and then lands after getting a wall reading. And tests are still going on for a fully automatic flight.
|
||||
|
||||
## References
|
||||
|
||||
[^1]: “The 20 deadliest jobs in America, ranked,” CBS News. https://www.cbsnews.com/pictures/the-20-deadliest-jobs-in-america-ranked/4/.
|
||||
[^2]: A. Kovalchenko, “How To Carry Out a Survey and Site Measure,” 2012. https://essenziale-hd.com/2012/10/28/how-to-carry-out-a-survey-and-site-measure/.
|
||||
[^3]: D. Hähnel, W. Burgard, and S. Thurn, “Learning compact 3D models of indoor and outdoor environments with a mobile robot,” Rob. Auton. Syst., vol. 44, no. 1, pp. 15–27, 2003, doi: 10.1016/S0921-8890(03)00007-1.
|
||||
[^4]: M. Eliwa, A. Adham, I. Sami, and M. Eldeeb, “A critical comparison between Fast and Hector SLAM algorithms,” / REST J. Emerg. trends Model. Manuf., vol. 3, no. 2, pp. 44–49, 2017, [Online]. Available: www.restpublisher.com/journals/jemm.
|
||||
[^5]: J. M. Santos, D. Portugal, and R. P. Rocha, “An evaluation of 2D SLAM techniques available in Robot Operating System,” 2013 IEEE Int. Symp. Safety, Secur. Rescue Robot. SSRR 2013, 2013, doi: 10.1109/SSRR.2013.6719348.
|
||||
[^6]: H. Gossett, “Building an Autonomous Indoor Drone System,” University of Mississippi, 2018.
|
||||
5
docs/en/events.md
Normal file
5
docs/en/events.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Events
|
||||
|
||||
Clover is being used in a lot of educational events and competitions, such as WorldSkills, NTI Olypics, Copter Hack, Innopolis Open Robotics, etc.
|
||||
|
||||
This section contains articles written specifically for a particular event.
|
||||
94
docs/en/fpv_clover_4_2.md
Normal file
94
docs/en/fpv_clover_4_2.md
Normal file
@@ -0,0 +1,94 @@
|
||||
# Installing and configuring FPV equipment
|
||||
|
||||
## Preparing and installing the FPV camera and transmitter
|
||||
|
||||
1. Install the small mounting deck onto the main frame.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_1.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_2.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
2. Install the camera mount bracket into the corresponding holes.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_3.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_4.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
3. Cut the three-pin supplied camera cable.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_5.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_6.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
4. Tin the wires
|
||||
|
||||
<img src="../assets/fpv/fpv_7.png" width=300 class="zoom border center">
|
||||
|
||||
5. Solder the JST-male connector to the power wires of the camera.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_8.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_9.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
> **Hint** Сheck what you are wearing shrink tubes before soldering the wires.
|
||||
|
||||
6. Solder the JST male connector to the transmitter.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_10.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_11.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
7. Solder the yellow camera signal cable to the transmitter.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_12.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_13.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
8. Connect the antenna to the transmitter.
|
||||
|
||||
<img src="../assets/fpv/fpv_14.png" width=300 class="zoom border center">
|
||||
|
||||
> **Caution** If voltage is applied to a transmitter without an antenna, there is a high probability that it will burn out.
|
||||
|
||||
9. Place the receiver onto the mounting deck, securing it with ties.
|
||||
|
||||
<img src="../assets/fpv/fpv_15.png" width=300 class="zoom border center">
|
||||
|
||||
10. Place the mounting deck with the receiver on the bottom of the aircraft.
|
||||
|
||||
<img src="../assets/fpv/fpv_16.png" width=300 class="zoom border center">
|
||||
|
||||
11. Place the camera in the bracket and secure it with the 4 attached bolts. The camera should be at an angle of 15°-20° relative to the plane of the aircraft.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_17.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_18.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/fpv/fpv_19.png" width=300 class="zoom border">
|
||||
<img src="../assets/fpv/fpv_20.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
12. Connect the signal cable to the camera.
|
||||
|
||||
<img src="../assets/fpv/fpv_21.png" width=300 class="zoom border center">
|
||||
|
||||
13. Connect the camera's power cable to the power JST soldered to the *BAT+* and *GND* pads on the power distribution board.
|
||||
|
||||
14. Connect the transmitter power cable to JST at 5V.
|
||||
|
||||
<img src="../assets/fpv/fpv_22.png" width=300 class="zoom border center">
|
||||
|
||||
## Setting up and connecting FPV goggles
|
||||
|
||||
1. Install the two supplied antennas on the glasses.
|
||||
2. Turn on the glasses by holding the power button for 3-4 seconds.
|
||||
3. Turn on the aircraft and make sure the transmitter LED is blue.
|
||||
4. Press the *Auto Search* button on the glasses to automatically search for an available radio channel.
|
||||
95
docs/en/generative_design_frame.md
Normal file
95
docs/en/generative_design_frame.md
Normal file
@@ -0,0 +1,95 @@
|
||||
# 3D-printed Generative Design Frame
|
||||
|
||||
## ADDI Copterhack 2021 Project
|
||||
|
||||
<iframe width="640" height="480" src="https://www.youtube.com/embed/EAGNmtpuTDc" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
### Contact
|
||||
|
||||
[Website](https://www.aachen-drone.de),
|
||||
[Mail](mailto:daniel.honies@rwth-aachen.de),
|
||||
Telegram: @danielhonies.
|
||||
|
||||
## Introduction
|
||||
|
||||
At the Aachen Drone Development Initiative we aim to develop a new frame for the clover drone by implementing the latest state of the art CAD-Design techniques as well as advanced manufacturing methods.
|
||||
|
||||
Three main goals have to be taken into consideration when designing a new frame:
|
||||
|
||||
- Decreasing the Weight
|
||||
- Improving Durability
|
||||
- Increasing Safety
|
||||
|
||||
For the first stage of the design we will focus on the first two points.
|
||||
|
||||
## Software
|
||||
|
||||
For designing our drone we use Autodesk Fusion 360. It comes with a generative design feature. This makes it possible to create rule-driven designs. First the preserved geometry is defined. Usually this includes all kinds of mounts like motor mounts, flight controller mounts, RPi mount etc. Then obstacle geometry is defined. This for example includes space for the propellers and the airflow. After that forces are defined. Then Fusion 360 will automatically calculate optimal connections for the aforementioned preserved geometry.
|
||||
|
||||
<p float="left">
|
||||
<img src="../assets/generative-design-frame/preservedgeometry.png" width="49%" class="zoom"/>
|
||||
<img src="../assets/generative-design-frame/obstacle.png" width="49%" class="zoom"/>
|
||||
</p>
|
||||
|
||||
### Prototypes
|
||||
|
||||
#### Prototype 1
|
||||
|
||||
After printing the first version of the frame we discovered the following problems:
|
||||
|
||||
- Bad Filament: Layer Adhesion of the Filament was quite bad resulting in a not very rigid model
|
||||
- Support Structure: The support structure for the frame is very complex and the parameters used in the slicer resulted in it being unable to be removed without destroying the model
|
||||
- Arm Strength: Some parts of the arms to the motor mounts were very thin, resulting in them breaking easily and removing the support structure resulted in breaking them
|
||||
|
||||
To conquer those problems we made several changes. We increased the minimal thickness for the generated structures and generated a new model. We changed the settings in the slicer so that the support structure could be removed easier as well as changed the infill structure. Finally we changed the filament and increased the printing temperature. Further we concluded that printing with a water dissolvable support structure would be optimal, however as of right now we don’t have access to a printer capable of that.
|
||||
|
||||
|
||||
|
||||
#### Prototype 2
|
||||
|
||||
This prototype took 48 hours of printing and used 277 grams of filament including 100 grams for the support. Installation of the components is very easy as no other tools than a screwdriver are needed. This prototype was the first to take flight in January 2021. Please see [this](https://youtu.be/M4f8_JmJADM) video.
|
||||
|
||||
<p float="left">
|
||||
<img src="../assets/generative-design-frame/p21.JPG" width="32%" class="zoom"/>
|
||||
<img src="../assets/generative-design-frame/p22.jpg" width="32%" class="zoom"/>
|
||||
<img src="../assets/generative-design-frame/p23.jpg" width="32%" class="zoom"/>
|
||||
</p>
|
||||
|
||||
#### Prototype 3
|
||||
|
||||
This prototype is even more optimised than the last one. Excluding support the model only weighs 141 grams. For this version we have also developed a prop guard, which weighs around 80 grams. Weight of the drone with the prop guard and a 2200mah battery is under 700 grams. Flight testing in the following videos shows the effectiveness of the prop guard. We also did some drop tests with this model and figured that a drop height of around 1 meter can be sustained. We plan to optimise this while sacrificing a bit of weight in February.
|
||||
|
||||
Videos:
|
||||
|
||||
- [Flight Test](https://youtu.be/uJjnMzz1Nm0)
|
||||
- [Prop Guard Test](https://youtu.be/UdnqIuXV2UI)
|
||||
|
||||
<p float="left">
|
||||
<img src="../assets/generative-design-frame/p31.jpg" width="49%" class="zoom"/>
|
||||
<img src="../assets/generative-design-frame/p32.jpg" width="49%" class="zoom"/>
|
||||
</p>
|
||||
|
||||
#### Final Prototype
|
||||
|
||||
In this final prototype we have changed the preserved geometry on the bottom to form a rectangle for added stability. We have also changed some of the forces on the points we observed breakings in our previous tests. We have also updated the prop guard to make it more stable and increased the area around the screws, so it would break harder. The frame without the prop guard weighs only 150g making it significantly lighter than the default frame.
|
||||
|
||||
|
||||
|
||||
### Benefits
|
||||
|
||||
We see the following benefits with our design over the traditional clover frame design:
|
||||
|
||||
- Tools needed for production: only a 3D printer is needed compared to laser cutter, cnc and 3D printer
|
||||
- Single material reduces supply chain complexity and reduces cost. Filament is cheap and only around 400 grams are needed for the full frame and the prop guard. This should reduce the cost to under $5.
|
||||
- The unibody design saves weight and much less screws are needed. This also reduces costs.
|
||||
- Easier adaptability: Anybody can change the frame to their desire and include their own adapters and mounts. It can be printed by any standard sized 3D printer. (Ender-3, Prusa etc.)
|
||||
- Manual labor reduced: Printing is easy to automate, packing is significantly reduced as less screws need to be counted etc.
|
||||
|
||||
### Conclusion
|
||||
|
||||
In our work for this years competition we presented a new way to design and manufacture drone frames. By utilizing state of the art methods of CAD programs we are able to optimize the weight and shape of drone frames in a way that for the first time it is feasible to 3D print them. In total we have printed around 10 frames and presented a few of them above and the challenges we faced with them. This iterative process to frame design was only possible due to the fact that only a 3D printer is needed and the filament being very cheap. Due to the open source nature of the project and this report giving a short introduction into generative design, we hope that many people feel inspired to check out this new method of designing and producing drone frames.
|
||||
|
||||
### CAD Files
|
||||
|
||||
You are welcome to test out these frame yourself and you are free to modify them in any way, shape or form. We would appreciate feedback and encourage submitting your modifications in a pull request so other people can benefit from this open source development.
|
||||
The CAD Files can be found on our [GitHub Page](https://github.com/Aachen-Drone-Development-Initiative/generative-clover-frame).
|
||||
@@ -86,6 +86,8 @@ How it works: Works from DC. I.e., by applying voltage from a DC source (a batte
|
||||
|
||||
* Rapid wear
|
||||
|
||||
### Brushless motors
|
||||
|
||||
Brushless motors, in which the moving part is the stator, are more efficient than brush-type motors. This is achieved due to the absence of brushes. However, since motor design is much more complicated, they are more expensive.
|
||||
|
||||
**Advantages:**
|
||||
|
||||
65
docs/en/magnetic_grip.md
Normal file
65
docs/en/magnetic_grip.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# Assembling and setting up the electromagnetic gripper
|
||||
|
||||
The magnetic gripper can be assembled in various ways according to the wiring diagram.
|
||||
|
||||
<img src="../assets/magnet_grip/scheme.jpg" width=300 class="zoom border center">
|
||||
|
||||
The following is an example of assembling an electromagnetic capture circuit on a breadboard.
|
||||
|
||||
> **Info** It is recommended to lay the wiring between the elements on the back side of the board (in the following images, the wiring is done over the diagram for illustrative purpose).
|
||||
|
||||
1. Place the Schottky diode, 10K resistor, and transistor on the soldering board.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Solder the contacts on the other side of the board and bite off the remaining element legs.
|
||||
3. Connect the pins of the resistor and the two outer legs of the transistor.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet2.png" width=300 class="zoom border center">
|
||||
|
||||
4. Connect the center leg of the transistor and the leg of the Schottky diode (opposite to the gray marking strip).
|
||||
|
||||
<img src="../assets/magnet_grip/magnet3.png" width=300 class="zoom border center">
|
||||
|
||||
5. Cut the required amount of magnetic grab wire and solder it to the pins of the Schottky diode.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet4.png" width=300 class="zoom border center">
|
||||
|
||||
6. Solder the *Dupont* - male wires to the transistor and diode leg (red, black wires), and the *Dupont* - fmale wire to the opposite transistor leg (white wire).
|
||||
|
||||
<img src="../assets/magnet_grip/magnet5.png" width=300 class="zoom border center">
|
||||
|
||||
## Checking the operation of the electromagnetic gripper
|
||||
|
||||
In order to check the operation of the gripper, apply a voltage of 5V to the signal wire. You can use the *Dupont* dad-dad wire for that.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet_check.png" width=300 class="zoom border center">
|
||||
|
||||
After applying voltage, the magnet should turn on.
|
||||
|
||||
## Connecting to Raspberry Pi
|
||||
|
||||
Connect the magnetic gripper to a Raspberry Pi for software activation.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet_raspberry.png" width=300 class="zoom border center">
|
||||
|
||||
An example of the code activating the magnetic gripper can be found [here](gpio.md#connecting-an-electromagnet).
|
||||
|
||||
## Connecting to Arduino
|
||||
|
||||
Connect the gripper to the Arduino Nano board in order to control it manually.
|
||||
|
||||
It is convenient to place it on the same soldering board — insert it into the appropriate holes and solder it from the back to the board.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet_arduino1.png" width=300 class="zoom border center">
|
||||
|
||||
Then connect the signal output of the circuit to the selected port and solder the *Dupont* female wire to the selected signal port on the board.
|
||||
|
||||
<img src="../assets/magnet_grip/magnet_arduino2.png" width=300 class="zoom border center">
|
||||
|
||||
## Installation of electromagnetic gripper
|
||||
|
||||
1. Install an electromagnet into the center hole on the gripper deck.
|
||||
2. Use a zip tie to pull the assembled circuit to the back of the deck.
|
||||
3. Plug the Arduino *D11* signal pin into one of the *AUX* pins on the flight controller.
|
||||
4. Plug the power wire of the electromagnetic gripper to JST 5V.
|
||||
69
docs/en/mechanical_grip.md
Normal file
69
docs/en/mechanical_grip.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# Assembling and setting up a mechanical gripper
|
||||
|
||||
1. Combine the main gripper plates.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Install the servo in the appropriate groove in the center of the plates with the axle gear in the middle.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_2.png" width=300 class="zoom border center">
|
||||
|
||||
3. Hold down the gripper plates with the small spacers.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/mechanical_grip/mech_grip_3.png" width=300 class="zoom border">
|
||||
<img src="../assets/mechanical_grip/mech_grip_4.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
4. Install the gripper deck so that the mounting holes in the grapple correspond with the self-tapping holes in the plate.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_5.png" width=300 class="zoom border center">
|
||||
|
||||
5. Fix the gripper structure with self-tapping screws.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_6.png" width=300 class="zoom border center">
|
||||
|
||||
6. Turn the servo gear to the end position.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_7.png" width=300 class="zoom border center">
|
||||
|
||||
7. Install the cruciform mount onto the gear and secure it using the screw attached to the servo.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_8.png" width=300 class="zoom border center">
|
||||
|
||||
8. Cut the cruciform mount.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/mechanical_grip/mech_grip_9.png" width=300 class="zoom border">
|
||||
<img src="../assets/mechanical_grip/mech_grip_10.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
9. Tie the servo thread so that there is a 2 to 3 cm margin.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/mechanical_grip/mech_grip_11.png" width=300 class="zoom border">
|
||||
<img src="../assets/mechanical_grip/mech_grip_12.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
10. Thread the servo thread into the corresponding tensioning slots.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_13.png" width=300 class="zoom border center">
|
||||
|
||||
11. Fasten the grip claws with small self-tapping screws so that their angle is 25°–40°.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_14.png" width=300 class="zoom border center">
|
||||
|
||||
12. Install the assembled grip onto the aircraft from below.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/mechanical_grip/mech_grip_16.png" width=300 class="zoom border">
|
||||
<img src="../assets/mechanical_grip/mech_grip_17.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
13. Insert the servo cable into the *AUX* 1-2 output on the flight controller.
|
||||
|
||||
<img src="../assets/mechanical_grip/mech_grip_18.png" width=300 class="zoom border center">
|
||||
|
||||
14. Go to the *Radio* tab to control capture with the remote control.
|
||||
15. In the *AUX 1/2 Passthrough RC channel* parameter, select the desired channel.
|
||||
16. Now, when you switch the toggle switch of the corresponding channel, the capture will be closed or opened.
|
||||
@@ -80,6 +80,24 @@ This page contains models and drawings of some of the drone parts. They can be u
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Clover 4.2 WorldSkills
|
||||
|
||||
### Milling
|
||||
|
||||
<table>
|
||||
<tr><th width=150>Preview</th><th>Part</th><th width=1>File</th></tr>
|
||||
<tr>
|
||||
<td><img src="../assets/dxf/4.2/big_leg.png"></td>
|
||||
<td>
|
||||
<b>Big leg</b>.<br>
|
||||
Function: Extended footing element.<br>
|
||||
Материал: Monolithic polycarbonate 2mm.<br>
|
||||
Quantity: 2 шт.
|
||||
</td>
|
||||
<td><a href="https://github.com/CopterExpress/clover/raw/master/docs/assets/dxf/4.2/big_leg.dxf"><code>big_leg.dxf</code></a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Clover 4
|
||||
|
||||
### 3D print
|
||||
|
||||
@@ -6,7 +6,7 @@ In order to configure flight modes:
|
||||
|
||||
1. Open the *Vehicle Setup* tab in QGroundControl.
|
||||
2. Select the *Flight Modes* menu.
|
||||
3. Choose SwC (Channel 5) as mode selection switch.
|
||||
3. Choose SwC (Channel 6) as mode selection switch.
|
||||
4. Set desired flight modes.
|
||||
|
||||
The following flight modes are recommended:
|
||||
@@ -16,7 +16,7 @@ In order to configure flight modes:
|
||||
* Flight Mode 6: *Position*.
|
||||
|
||||
5. Check mode switching by changing the switch position.
|
||||
6. Choose SwA (Channel 6) as emergency motor stop (*Kill switch*).
|
||||
6. Choose SwA (Channel 5) as emergency motor stop (*Kill switch*).
|
||||
|
||||
<img src="../assets/qgc-modes.png" class="zoom" alt="QGroundControl modes">
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ If there is no voltage indicator or manual calibration is not possible, set the
|
||||
* Put the battery voltage into the prompt and click *Calculate*.
|
||||
* Press *Close* to save the calculated value.
|
||||
|
||||
<img src="../assets/qgc-battery.png" class="zoom">
|
||||
<img src="../assets/qgc-voltage-divider.png" class="zoom">
|
||||
|
||||
Further reading: https://docs.qgroundcontrol.com/en/SetupView/Power.html.
|
||||
|
||||
@@ -28,7 +28,7 @@ Further reading: https://docs.qgroundcontrol.com/en/SetupView/Power.html.
|
||||
3. Connect the battery when prompted.
|
||||
4. Wait for the *Calibration complete*.
|
||||
|
||||
<img src="../assets/qgc-esc.png" class="zoom">
|
||||
<img src="../assets/qgc-power.png" class="zoom">
|
||||
|
||||
Further reading: https://docs.px4.io/v1.9.0/en/advanced_config/esc_calibration.html.
|
||||
|
||||
|
||||
322
docs/en/seeding_drone.md
Normal file
322
docs/en/seeding_drone.md
Normal file
@@ -0,0 +1,322 @@
|
||||
# Seed spreading quadcopter
|
||||
|
||||
[CopterHack-2021](copterhack2021.md), team **MINIONS**.
|
||||
|
||||
Have you ever wondered what a world without trees would look like? Close your eyes, and try to imagine a desolate Earth. There'd be no more paper, and everyone would have to resort to technological use - that is, if anyone was left. Trees are a crucial factor to our existence not only because they produce paper, lumber and chewing gum, but because they serve an important role in the carbon cycle.
|
||||
|
||||
Ever since the industrial revolution between 1760 and 1840, the world has been in a never-ending carbon chaos. Trees and Plankton are our only saviours in terms of handling this problem, and we can only control one of them, trees.
|
||||
|
||||
We need to save trees by protecting them from the destructive human activities like clearance of forests, deforestation for urbanization, etc. Trees are the lungs for the earth. It is an important part of nature’s ecosystem. They balance the soil composition and also act as the barrier for wind and storm. Thus, they provide various uses to the ecosystem. For these reasons, it’s imperative that we save trees.
|
||||
|
||||
Since there are a lot of dangerous and difficult-to-reach landsides for humans to plant, the most viable alternative is to use drones for plantation in those regions.
|
||||
|
||||
Seed-firing drones will, as the name suggests, fire seeds into fertile soil to allow millions of trees to grow back after being cut down for industrial use. If the rate of planting exceeds the rate of cutting, eventually we will restore the trees we once felled.
|
||||
|
||||
<img src="../assets/seeding_drone/image.jpg" alt="" width="400px" class="center"/>
|
||||
|
||||
## Our Aim
|
||||
|
||||
We will make drones able to hold seeds onboard and drop them in an area which we drove in a special application. We can control the density of the seeds and the height of the drop. We also thought about protection of the seeds from insects, animals and dehydration. We choose the earth ball technique invented by Masanobu Fukuoka, aka Fukuoka Technique. This earth ball contains all needed elements to grow, plant seeds and earth for protection. When we drop it on the ground, the earth ball will hold seeds until it gets the needed amount of water and seeds will begin to grow.
|
||||
|
||||
YouTube video link - [https://www.youtube.com/embed/Nz1w59v451U](https://www.youtube.com/embed/Nz1w59v451U).
|
||||
|
||||
We achieved to do small seeding missions but we faced some problem about autonomous flying with GPS.
|
||||
|
||||
We coated our battery to protect it from cold weather, seeding missions need to start in winter since apple seeds need to stay in a cold place for some time to break dormancy.
|
||||
|
||||
- [Seed capsules](#seed-capsules)
|
||||
- [How to assemble seeding mechanism to clover 4.2 drone](#how-to-assemble-seeding-mechanism-to-clover-42-drone)
|
||||
- [How to control the seeding mechanism](#how-to-control-the-seeding-mechanism)
|
||||
- [Programming](#programming)
|
||||
|
||||
## Files
|
||||
|
||||
Link for the all files used in this project: [https://github.com/Sahinysf/TreeSeedQuad](https://github.com/Sahinysf/TreeSeedQuad).
|
||||
|
||||
## Seed capsules
|
||||
|
||||
### Fukuoka technique
|
||||
|
||||
In southern Japan, the Japanese farmer and philosopher Masanobu Fukuoka invented a seed ball planting technique. The method is regarded as a natural farming technique that requires no machines, no chemicals and very little weeding. By the use of seed balls, land is cultivated without any soil preparation.
|
||||
|
||||
<img src="../assets/seeding_drone/seedcapsules/1.jpg" width="250px" class="center"/>
|
||||
|
||||
Advantages of seed balls:
|
||||
|
||||
- It is simple and easier to make seed balls without machines.
|
||||
- Easier for reforestation and plantation in difficult terrains.
|
||||
- Contribute to protect soil, environment and livelihood.
|
||||
- It is an organic technique and doesn’t use any chemicals.
|
||||
- It is a low-cost method compared to traditional afforestation/reforestation techniques.
|
||||
- It requires low maintenance.
|
||||
|
||||
### Which Seeds can be used?
|
||||
|
||||
Any seed which grows in your area (In our it’s apple seed).
|
||||
|
||||
Size and weight of the seed capsule: size and Weight of seed capsules are very important for this project. After some experiments we decided that best size is 16-18mm diameter and maximum weight is 10 g.
|
||||
|
||||
Required materials for making seed balls:
|
||||
|
||||
1. 1 bucket of clay
|
||||
2. 1 bucket of organic dark soil / compost
|
||||
3. 1 bucket of water (amount of water may vary depending on the soil type)
|
||||
4. ¼ bucket of seeds
|
||||
|
||||
Steps for making seed balls:
|
||||
|
||||
1. Collect same quantity of both clay and organic soil. For example, if you use one bucket of clay, then you should mix with one bucket of organic soil.
|
||||
2. Make sure that clay and organic soil fine particles.
|
||||
3. The clay and organic soil texture should be wet but not sticky
|
||||
4. Take a bit of mixture and roll it into balls. Test the ball by throwing it on a flat surface. If the ball doesn’t break easily, it means it has got good bonding.
|
||||
5. Seed balls must be a perfectly round shape otherwise they will be stuck while throwing with the quadcopter
|
||||
6. Insert seeds (1 to 2 seeds per seed ball for permanent trees such as mahogany, sandalwood, orange, moringa…) (± 5 seeds per seed ball for vegetables, flowers, grasses, clovers…)
|
||||
7. Dry the seed balls for one to two days in a shaded area, if properly dry, the seed balls will be protected from external predators such as chickens, birds, rats…
|
||||
|
||||
<img src="../assets/seeding_drone/seedcapsules/3.jpg" width="250px" class="center"/>
|
||||
|
||||
Second technique - paper seed capsules.
|
||||
|
||||
This method was influenced by a Korean newspaper that contained seed that could be planted outside after reading it.
|
||||
Paper seed capsules :
|
||||
|
||||
Required materials:
|
||||
|
||||
1. Any kind of paper
|
||||
2. Water
|
||||
3. Blender
|
||||
4. Seeds
|
||||
|
||||
Steps for making paper seed balls:
|
||||
|
||||
1. Shred all of your paper.
|
||||
2. Put paper in blender and add water, after 2 minutes blend.
|
||||
3. Squeeze all the water out with paper.
|
||||
4. Add seeds and give round shape.
|
||||
5. Let it dry overnight.
|
||||
|
||||
<img src="../assets/seeding_drone/seedcapsules/2.jpg" width="400px" class="center"/>
|
||||
|
||||
Advantages of paper balls:
|
||||
|
||||
- Easy to find materials.
|
||||
- Environmentally friendly.
|
||||
|
||||
REREFENCES
|
||||
|
||||
<https://web.archive.org/web/20090115211020/http://www.rmaf.org.ph/Awardees/Biography/BiographyFukuokaMas.htm>
|
||||
<http://www.guerrillagardening.org/ggseedbombs.html>
|
||||
|
||||
## How to assemble seeding mechanism to Clover 4.2 drone
|
||||
|
||||
### How to assemble seeding mechanism
|
||||
|
||||
After finishing step 4, at section Installing guard of Clover 4.2 assembly.
|
||||
|
||||
1. Install the Lower Tank Holders to top Deck mount and fix with the M3x8 screws.
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/1.PNG" width="400px" class="center"/>
|
||||
|
||||
2. Install Nylon rack(40 mm) to 4 sides of the Deck mount.
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/2.PNG" width="400px" class="center"/>
|
||||
|
||||
3. Install the Grab deck and fix with the M3x8 screws.
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/3.PNG" width="400px" class="center"/>
|
||||
|
||||
4. Install the Upper Tank Holders to top Grab mount and fix with the M3x8 screws.
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/4.PNG" width="400px" class="center"/>
|
||||
|
||||
5. Connect the Tanks carefully to Tank Holders.
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/5.PNG" width="400px" class="center"/>
|
||||
|
||||
6. Connect SG90 servo motors to Tank using zip tie.
|
||||
|
||||
Final view of seeding drone:
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/6.jpg" alt="" width="400px" class="center"/>
|
||||
|
||||
### GPS Module
|
||||
|
||||
We installed the GPS Module to the top using 2 Nylon rack (40 mm):
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/7.jpg" alt="" width="400px" class="center"/>
|
||||
|
||||
We coated the battery to protect it from the cold weather:
|
||||
|
||||
<img src="../assets/seeding_drone/mechanismpictures/8.jpg" alt="" width="400px" class="center"/>
|
||||
|
||||
## How to control the seeding mechanism
|
||||
|
||||
Electronic part of seed dropping mechanism consists of:
|
||||
|
||||
- Raspberry Pi 4 B of COEX Clover 4.
|
||||
- 2 Micro Servo Motors SG90.
|
||||
- PDB (Power Distribution Board) of COEX Clover 4.
|
||||
|
||||
Servo motor’s signal pins are connected to Raspberry Pi’s Hardware PWM pins 32 and 33, and power is taken from Power Distribution Board (5 V).
|
||||
|
||||
<img src="../assets/seeding_drone/electronicspictures/electronic1.png" alt="" width="400px" class="center"/>
|
||||
|
||||
### Explanation of code for controlling servo motors
|
||||
|
||||
Servo motors are controlled using a PWM (Pulse-Width Modulation) signal from Raspberry Pi. PWM controls the amount of time when signal is HIGH or LOW within a certain period of time. Duty Cycle – percentage of time when signal is HIGH.
|
||||
|
||||
In a table below it's presented the duty cycle of Servo Motor SG90 of each angle of servo motor. In order to use duty cycle in code we need to convert time to percentage by dividing duty cycle time by the total PWM period.
|
||||
|
||||
What we get is:
|
||||
|
||||
- -90° rotation angle or 2ms Duty Cycle => 1/20*100% = 5% Duty Cycle.
|
||||
- 90° rotation angle or 2ms Duty Cycle => 2/20*100% = 10% Duty Cycle.
|
||||
- 0° rotation angle or 1,5ms Duty Cycle => 1,5/20*100% = 7,5% Duty Cycle.
|
||||
|
||||
<img src="../assets/seeding_drone/electronicspictures/electronic2.png" alt="" width="400px" class="center"/>
|
||||
|
||||
We’ll do this by using the RPi.GPIO library and writing Python code on the Raspberry Pi.
|
||||
|
||||
First, import the RPi.GPIO library and the sleep function:
|
||||
|
||||
```python
|
||||
import RPi.GPIO as GPIO
|
||||
from time import sleep
|
||||
```
|
||||
|
||||
Then, setup the GPIO mode as BOARD:
|
||||
|
||||
```python
|
||||
servo = 33
|
||||
GPIO.setmode(GPIO.BOARD)
|
||||
GPIO.setup(servo, GPIO.OUT)
|
||||
```
|
||||
|
||||
Next, create a variable for the servo, PWM. Then, send a 50 Hz PWM signal on that GPIO pin using the `GPIO.PWM` function. Start the signal at 0:
|
||||
|
||||
```python
|
||||
pwm=GPIO.PWM(servo, 50)
|
||||
pwm.start(0)
|
||||
```
|
||||
|
||||
Use the `ChangeDutyCycle` function to write duty cycle percentages to the servo motor.
|
||||
|
||||
```python
|
||||
pwm.ChangeDutyCycle(5) # left -90 deg position
|
||||
sleep(1)
|
||||
pwm.ChangeDutyCycle(7.5) # neutral position
|
||||
sleep(1)
|
||||
pwm.ChangeDutyCycle(10) # right +90 deg position
|
||||
sleep(1)
|
||||
```
|
||||
|
||||
## Programming
|
||||
|
||||
In order for the mission to be achievable in the best way and within our reach, we were required to utilize the threading in Python.
|
||||
|
||||
Simple mission code:
|
||||
|
||||
```py
|
||||
import threading
|
||||
import time
|
||||
import rospy
|
||||
from clover import srv
|
||||
from std_srvs.srv import Trigger
|
||||
import RPi.GPIO as GPIO
|
||||
|
||||
rospy.init_node('flight')
|
||||
|
||||
get_telemetry = rospy.ServiceProxy('get_telemetry', srv.GetTelemetry)
|
||||
navigate = rospy.ServiceProxy('navigate', srv.Navigate)
|
||||
navigate_global = rospy.ServiceProxy('navigate_global', srv.NavigateGlobal)
|
||||
set_position = rospy.ServiceProxy('set_position', srv.SetPosition)
|
||||
set_velocity = rospy.ServiceProxy('set_velocity', srv.SetVelocity)
|
||||
set_attitude = rospy.ServiceProxy('set_attitude', srv.SetAttitude)
|
||||
set_rates = rospy.ServiceProxy('set_rates', srv.SetRates)
|
||||
land = rospy.ServiceProxy('land', Trigger)
|
||||
|
||||
servo1 = 33 # PWM pins
|
||||
servo2 = 32
|
||||
|
||||
GPIO.setmode(GPIO.BOARD) #set pin numbering system
|
||||
|
||||
GPIO.setup(servo1,GPIO.OUT)
|
||||
GPIO.setup(servo2,GPIO.OUT)
|
||||
|
||||
pwm1 = GPIO.PWM(servo1,50) #create PWM instance with frequency
|
||||
pwm2 = GPIO.PWM(servo2,50)
|
||||
|
||||
pwm1.start(0) #start PWM of required Duty Cycle
|
||||
pwm2.start(0)
|
||||
|
||||
|
||||
def servo_drop(seconds): #function to drop seed capsules from 2 tanks
|
||||
print("Dropping")
|
||||
|
||||
i = 1 #variable to choose which tank
|
||||
for num in range(seconds/2):
|
||||
if(i == 1): #first tank
|
||||
pwm1.ChangeDutyCycle(10) # release one seed capsule
|
||||
time.sleep(0.5)
|
||||
pwm1.ChangeDutyCycle(5) # push then drop the capsule
|
||||
time.sleep(0.5)
|
||||
i = 2 #changing the variable for to use the second tank in next dropping
|
||||
|
||||
elif(i == 2): #first tank
|
||||
pwm2.ChangeDutyCycle(10) # release one seed capsule
|
||||
time.sleep(0.5)
|
||||
pwm2.ChangeDutyCycle(5) # push then drop the capsule
|
||||
time.sleep(0.5)
|
||||
i = 1 #changing the variable for to use the first tank in next dropping
|
||||
|
||||
print(num)
|
||||
time.sleep(2)
|
||||
|
||||
|
||||
if name == "main":
|
||||
# Take off and drone 10m above the ground
|
||||
navigate(x=0, y=0, z=10, frame_id='body', auto_arm=True)
|
||||
|
||||
# rospy waits for 10 seconds to take off
|
||||
rospy.sleep(10)
|
||||
|
||||
# Dropping starts simultaneously with flying forwards 5 meters
|
||||
d = threading.Thread(target=servo_drop, args=(18,)) # 18 is the sum of all the time that the drone hovers after take off
|
||||
d.start()
|
||||
|
||||
navigate(x=5, y=0, z=0, frame_id='body')
|
||||
|
||||
#rospy waits for 8 seconds to fly forward
|
||||
rospy.sleep(8)
|
||||
|
||||
# Fly right 1 m
|
||||
navigate(x=0, y=1, z=0, frame_id='body')
|
||||
|
||||
#rospy waits for 2 seconds to fly right
|
||||
rospy.sleep(2)
|
||||
|
||||
# Fly backward 5 m
|
||||
navigate(x=-5, y=0, z=0, frame_id='body')
|
||||
|
||||
#rospy waits for 8 seconds to fly backward
|
||||
rospy.sleep(8)
|
||||
|
||||
# Perform landing
|
||||
land()
|
||||
|
||||
pwm1.stop()
|
||||
pwm2.stop()
|
||||
GPIO.cleanup()
|
||||
```
|
||||
|
||||
### References
|
||||
|
||||
- https://www.nationalgeographic.com/environment/article/deforestation
|
||||
- http://www.fao.org/fileadmin/templates/rap/files/NRE/Forestry_Group/Landslide_PolicyBrief.pdf
|
||||
- https://earthenginepartners.appspot.com/
|
||||
|
||||
## Developed by Team MINIONS
|
||||
|
||||
Special thanks to International Ala-Too University for funding the Clover 4 kits.
|
||||
|
||||
<img src="https://pms.alatoo.edu.kg/images/logo_text.png">
|
||||
@@ -29,6 +29,8 @@ Main article: https://docs.qgroundcontrol.com/en/SetupView/Firmware.html
|
||||
|
||||
We recommend using the modified version of PX4 by CopterExpress for the Clover drone, especially for autonomous flights. Download the latest stable version **<a class="latest-firmware v4" href="https://github.com/CopterExpress/Firmware/releases">from our GitHub</a>**.
|
||||
|
||||
> **Info** For Pixhawk-based quadcopters there is a separate firmware version. See details in "[Pixhawk / Pixracer firmware flashing](firmware.md)" article.
|
||||
|
||||
Flash the flight controller with this firmware:
|
||||
|
||||
<img src="../assets/qgc-firmware.png" alt="QGroundControl firmware upload" class="zoom">
|
||||
@@ -68,12 +70,12 @@ This is how the main QGroundControl settings window will look like:
|
||||
|
||||
### Selecting the airframe
|
||||
|
||||
<img src="../assets/qgc-frame-apply.png" alt="QGroundControl frame selection" class="zoom">
|
||||
<img src="../assets/qgc-frame-apply-clover4.png" alt="QGroundControl frame selection" class="zoom">
|
||||
|
||||
1. Open the *Vehicle Setup* tab.
|
||||
2. Select the *Airframe* menu.
|
||||
3. Select the *Quadrotor X* airframe type.
|
||||
4. Select the *Generic Quadrotor X* from the dropdown menu.
|
||||
4. For Clover 4 select *COEX Clover 4* from the dropdown menu. Otherwise select *Generic Quadrotor X*.
|
||||
5. Return to the top of the list and press *Apply and Restart* button, confirm by pressing *Apply*.
|
||||
6. Wait for the settings to be applied and for the flight controller to restart.
|
||||
|
||||
@@ -87,6 +89,8 @@ Press the *Save* button to save the changed value to the flight controller. Chan
|
||||
|
||||
#### Configuring PID regulators
|
||||
|
||||
> **Info** Selecting *COEX Clover 4* frame subtype doesn't require setting PID coefficients.
|
||||
|
||||
##### Averaged PID coefficients for the Clover 4 drone
|
||||
|
||||
* `MC_PITCHRATE_P` = 0.087
|
||||
|
||||
@@ -295,6 +295,8 @@ Parameters:
|
||||
* `thrust` — throttle level, ranges from 0 (no throttle, propellers are stopped) to 1 (full throttle).
|
||||
* `auto_arm` – switch the drone to `OFFBOARD` and arm automatically (**the drone will take off**);
|
||||
|
||||
The positive direction of `yaw_rate` rotation (when viewed from the top) is counterclockwise,`pitch_rate` rotation is forward, `roll_rate` rotation is to the left.
|
||||
|
||||
### land
|
||||
|
||||
Switch the drone to landing [mode](modes.md) (`AUTO.LAND` or similar).
|
||||
|
||||
@@ -32,3 +32,9 @@ The simulation environment is based on the following components:
|
||||
* ROS packages and Gazebo plugins.
|
||||
|
||||
<!-- TODO: Write more, add a diagram, etc -->
|
||||
|
||||
## Video
|
||||
|
||||
Short video review of the simulator:
|
||||
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/8HYXREMDfzQ" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
PX4 Simulation
|
||||
===
|
||||
|
||||
> **Hint** This article is about running a standalone PX4 simulation with a generic quadcopter. Consider using [our configuration](simulation.md) for a more Clover-like experience.
|
||||
> **Warning** This article is about running a standalone PX4 simulation with a generic quadcopter and **is outdated**. Consider using [our configuration](simulation.md) for a more Clover-like experience.
|
||||
|
||||
Main article: https://dev.px4.io/en/simulation/
|
||||
|
||||
|
||||
@@ -12,11 +12,11 @@ The distance gage is attached to the body using double-sided tape. For obtaining
|
||||
|
||||
### Connection
|
||||
|
||||
Connect HC-SR04 to Raspberry Pi according to the connection diagram. Use 1.0 and 2.2 kΩ resistors and any free GPIO pins, e.g., 23 and 24:
|
||||
Connect HC-SR04 to Raspberry Pi according to the connection diagram. Use 1.0 and 2.2 kΩ resistors and any free GPIO pins, e.g., 23 and 24:
|
||||
|
||||
<img src="../assets/raspberry-hc-sr04.png" alt="Connecting HC-SR04" height=600>
|
||||
|
||||
> **Hint** Instead of a 2.2 kΩ resistor, you can use two 1 kΩ resistors connected in series.
|
||||
> **Hint** Instead of a 2.2 kΩ resistor, you can use two 1 kΩ resistors connected in series.
|
||||
|
||||
<!-- -->
|
||||
|
||||
@@ -54,8 +54,8 @@ import time
|
||||
import threading
|
||||
import pigpio
|
||||
|
||||
TRIG = 23 is the No. of the pin connected to the Trig contact of the distance gage
|
||||
TRIG = 24 is the No. of the pin connected to the Echo contact of the distance gage
|
||||
TRIG = 23 # pin connected to the Trig pin of the sonar
|
||||
ECHO = 24 # pin connected to the Echo pin of the sonar
|
||||
|
||||
pi = pigpio.pi()
|
||||
done = threading.Event()
|
||||
|
||||
58
docs/en/wall_aruco.md
Normal file
58
docs/en/wall_aruco.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Navigation using vertical ArUco-markers
|
||||
|
||||
The algorithm of the navigation through visual ArUco-markers, that was implemented in the Clever image, supports the flexible configuration of the markers in area. It allows you to place them on any surface, at any angle.
|
||||
|
||||
## Installing the vertical camera mount
|
||||
|
||||
For a better recognition of the markers, you need to set the camera vertically so that the lens is pointed parallel to the horizon.
|
||||
|
||||
> **Note** The configuration file allows you to configure the location of the camera in area relative to the copter in any way. For your convenience, we will review the option of installing the camera at an angle of 90 degrees to the horizon in the direction of the copter's nose.
|
||||
|
||||
### Camera mount, 3D printing
|
||||
|
||||
Print the [camera mount](models.md#clover-3).
|
||||
|
||||
Install the mount in a convenient location, so that the camera has a minimum number of unnecessary objects (protection, legs, propellers, beams) — all of it will negatively affect the recognition of the markers.
|
||||
|
||||
## Setting the camera transform
|
||||
|
||||
To set the camera position at the desired angle, open the file `main_camera.launch`, located in `~/catkin_ws/src/clover/clover/launch/`.
|
||||
|
||||
```bash
|
||||
nano ~/catkin_ws/src/clover/clover/launch/main_camera.launch
|
||||
```
|
||||
|
||||
In the parameters `direction_x`, `direction_y`, set empty values manually or enter the following lines:
|
||||
|
||||
```bash
|
||||
sed -i "/direction_z/s/default=\".*\"/default=\"\"/" /home/pi/catkin_ws/src/clover/clover/launch/main_camera.launch
|
||||
sed -i "/direction_y/s/default=\".*\"/default=\"\"/" /home/pi/catkin_ws/src/clover/clover/launch/main_camera.launch
|
||||
```
|
||||
|
||||
Edit one of the configuration lines or add the line shown bellow:
|
||||
|
||||
```xml
|
||||
<node pkg="tf2_ros" type="static_transform_publisher" name="main_camera_frame" args="0.05 0 0.05 -1.5707963 0 -1.5707963 base_link main_camera_optical"/>
|
||||
```
|
||||
|
||||
> **Note**. Only one camera configuration can be used at a time. If you insert the line above, don't forget to comment the currently active one. The syntax highlighting system will help you determine that — the active line will be highlighted in a different color than the comments. To comment, add the `<!--` and `-->` symbols at the beginning and the end respectively.
|
||||
|
||||
If you are using the marker map, where the markers have equal distances along the x and y axes, you can use [script for creating markers map `gen_map.py`](aruco_map.md#marker-map-definition). Otherwise, you will need to set them manually. To do this, go to the directory `map_name.txt` and create a map file. Fill out your map according to the [map syntax](aruco_map.md#marker-map-definition). Here is an example of a marker map with a random marker location:
|
||||
|
||||
>**Hint**. When filling out the map, select one of the markers as the origin, and measure the distance to all other markers relative to it. If all your parameters are oriented same way, you can choose not to specify all 8 parameters, but only the first 5: the marker index, size, and its location in space along the x, y, and z axes, respectively.
|
||||
|
||||
```
|
||||
106 0.33 0 0 0
|
||||
103 0.33 1.53 0.23 0
|
||||
153 0.40 -0.56 1.36 0
|
||||
```
|
||||
|
||||
After you fill out the map, you need to apply it. To do it, edit the file `aruco.launch`, located in `~/catkin_ws/src/clover/clover/launch/`. Change the line `<param name="map" value="$(find aruco_pose)/map/map_name.txt"/>`, where `map_name.txt` is the name of your map file.
|
||||
|
||||
If you are using markers that are not linked to horizontal surfaces (floor, ceiling), you must disable the parameter `known_tilt` both in the module `aruco_detect` and `aruco_map` in the same file. To do it automatically, enter:
|
||||
|
||||
```bash
|
||||
sed -i "/known_tilt/s/value=\".*\"/value=\"\"/" /home/pi/catkin_ws/src/clover/clover/launch/aruco.launch
|
||||
```
|
||||
|
||||
After all the settings, call `sudo systemctl restart clover` to restart the `clover` service.
|
||||
183
docs/en/zerotire_vpn.md
Normal file
183
docs/en/zerotire_vpn.md
Normal file
@@ -0,0 +1,183 @@
|
||||
# Creating a virtual network ZeroTire One and connecting to it
|
||||
|
||||
## Creating and configuring a ZeroTire network
|
||||
|
||||
1. Go to [ZeroTire](https://www.zerotier.com/) website.
|
||||
|
||||
<img src="../assets/zerotire/login_1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Sign up on ZeroTire.
|
||||
|
||||
<img src="../assets/zerotire/login_2.png" width=300 class="zoom border center">
|
||||
|
||||
3. Go to your account.
|
||||
|
||||
4. Click on the *Create A Network*.
|
||||
|
||||
<img src="../assets/zerotire/network_1.png" width=300 class="zoom border center">
|
||||
|
||||
5. After that, you will see the network you created, its ID and name. Click on the network to configure it.
|
||||
|
||||
<img src="../assets/zerotire/network_2.png" width=300 class="zoom border center">
|
||||
|
||||
6. In the window that appears you can change the network name and connection privacy.
|
||||
|
||||
<img src="../assets/zerotire/network_3.png" width=300 class="zoom border center">
|
||||
|
||||
7. Scroll down to the *Members* column. It will say that there are no users on the network.
|
||||
|
||||
<img src="../assets/zerotire/network_4.png" width=300 class="zoom border center">
|
||||
|
||||
8. Devices connected to the network will be displayed in this column. To allow them to connect to the network, activate the *Auth?* checkbox. The connected device will automatically be given an internal IP address, which will then be used to communicate with this device.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/zerotire/network_5.png" width=300 class="zoom border">
|
||||
<img src="../assets/zerotire/network_6.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
> **Hint** specify names for new devices, it will help you distinguish them from each other in the future.
|
||||
|
||||
9. Repeat the last step for all the devices that you want to connect.
|
||||
|
||||
> **Info** ZeroTire network supports up to 50 users simultaneously for free use.
|
||||
|
||||
## Setup on Windows
|
||||
|
||||
### Installing the app
|
||||
|
||||
1. Go to the ZeroTire website.
|
||||
|
||||
<img src="../assets/zerotire/download_1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Click on the Windows icon.
|
||||
|
||||
<img src="../assets/zerotire/download_2.png" width=300 class="zoom border center">
|
||||
|
||||
3. Download and run the `Zero Tare One.msi` file.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/zerotire/windows_1.png" width=300 class="zoom border">
|
||||
<img src="../assets/zerotire/windows_2.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
### Network connection
|
||||
|
||||
1. Run ZeroTire One.
|
||||
|
||||
2. Click on the ZeroTire One icon in the taskbar.
|
||||
|
||||
3. Click on the *Join Network...* to connect to the network.
|
||||
|
||||
<img src="../assets/zerotire/windows_3.png" width=300 class="zoom border center">
|
||||
|
||||
4. In the window that appears, enter your network ID and click *Join*.
|
||||
|
||||
<img src="../assets/zerotire/windows_4.png" width=300 class="zoom border center">
|
||||
|
||||
5. Allow using the new network.
|
||||
|
||||
## Setup on iOS
|
||||
|
||||
### Installing the app
|
||||
|
||||
1. Go to the ZeroTire website.
|
||||
|
||||
<img src="../assets/zerotire/download_1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Click on the iOS icon.
|
||||
|
||||
<img src="../assets/zerotire/download_2.png" width=300 class="zoom border center">
|
||||
|
||||
3. Install the *ZeroTire One* app.
|
||||
|
||||
### Network connection
|
||||
|
||||
1. Run ZeroTire One app.
|
||||
|
||||
2. Click on *+* to add a new connection.
|
||||
|
||||
<img src="../assets/zerotire/ios_1.png" width=300 class="zoom border center">
|
||||
|
||||
3. Confirm the privacy policy.
|
||||
|
||||
<img src="../assets/zerotire/ios_2.png" width=300 class="zoom border center">
|
||||
|
||||
4. Enter your network ID and click *Add Network*.
|
||||
|
||||
<img src="../assets/zerotire/ios_3.png" width=300 class="zoom border center">
|
||||
|
||||
5. Confirm adding the new VPN configuration.
|
||||
|
||||
6. Connect to the VPN network by sliding the network activation slider.
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/zerotire/ios_4.png" width=300 class="zoom border">
|
||||
<img src="../assets/zerotire/ios_5.png" width=300 class="zoom border">
|
||||
</div>
|
||||
|
||||
## Setup on Linux (PC, Raspberry Pi)
|
||||
|
||||
### Installing the app
|
||||
|
||||
1. Open the console by pressing the keyboard shortcut *ctrl + alt + t* or type *terminal* in the program search bar.
|
||||
|
||||
2. Enter the Zero Tare installation command.
|
||||
|
||||
```bash
|
||||
curl -s https://install.zerotier.com | sudo bash
|
||||
```
|
||||
|
||||
### Network connection
|
||||
|
||||
1. Open the console.
|
||||
|
||||
2. Enter the command `sudo zerotire-cli join network-id`, where `network-id` is your network ID.
|
||||
|
||||
<img src="../assets/zerotire/linux_1.png" width=300 class="zoom border center">
|
||||
|
||||
3. If the connection is successful, the corresponding message will be displayed in the console.
|
||||
|
||||
## Installing and configuring on macOS
|
||||
|
||||
### Installing the app
|
||||
|
||||
1. Go to the ZeroTire website.
|
||||
|
||||
<img src="../assets/zerotire/download_1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Click on the macOS icon.
|
||||
|
||||
<img src="../assets/zerotire/download_2.png" width=300 class="zoom border center">
|
||||
|
||||
3. Download and run `ZeroTire One.pkg` file.
|
||||
|
||||
4. Install the ZeroTire One app.
|
||||
|
||||
### Network connection
|
||||
|
||||
1. Run ZeroTire One app.
|
||||
|
||||
2. Click on the ZeroTire One icon in the taskbar .
|
||||
|
||||
3. In the window that appears, click on *Join Network...*.
|
||||
|
||||
<img src="../assets/zerotire/macos_1.png" width=300 class="zoom border center">
|
||||
|
||||
4. In the *Enter Network ID* field, enter your network ID.
|
||||
|
||||
<img src="../assets/zerotire/macos_2.png" width=300 class="zoom border center">
|
||||
|
||||
## Connecting to the copter
|
||||
|
||||
1. Make sure that ZeroTire is working and connected to the network on the drone and control device. To do this, make sure that these have an *Online* status.
|
||||
|
||||
<img src="../assets/zerotire/qgc_1.png" width=300 class="zoom border center">
|
||||
|
||||
2. Make sure that all devices have local IP addresses - *Managed IPs*.
|
||||
|
||||
3. Open GQC and in the *Comm Links* tab add a TCP connection specifying the IP of the drone. Read more about remote connection [here](gcs_bridge.md).
|
||||
|
||||
<div class="image-group">
|
||||
<img src="../assets/zerotire/qgc_2.png" width=300 class="zoom border">
|
||||
<img src="../assets/zerotire/qgc_3.png" width=300 class="zoom border">
|
||||
</div>
|
||||
Reference in New Issue
Block a user