This project depends on MoveIt! framework and Gazebo 9. In order to get all necessary packages, run the commands:
sudo apt-get install gazebo9 libgazebo9-dev ros-melodic-gazebo9*rosdep install --from-paths src --ignore-src -r -y --rosdistro melodicAfter that, the repository should be cloned with all its submodules:
git clone --recurse-submodules https://github.com/tahsinkose/hector-moveit.gitSince, Github does not support partial submoduling yet, the package hector_gazebo_termal_camera should be deleted after above command is executed.
In order to build the project execute catkin build. Since there are roughly 30 packages, build time may be around 5 minutes.
To run the project, launch consecutively:
roslaunch hector_moveit_gazebo orchyard_navigation.launchroslaunch hector_moveit_exploration explore.launchHector Quadrotor with MoveIt! Motion Planning Framework.
This project aims a generic application that can autonomously manipulate a quadcopter with the minimal human-operator intervention. In order to implement Motion Planning primitives, MoveIt! framework is being used. This work highly inspires from the references outlied below.
The new thing is the usage of MoveIt! code API so as to implement a 3D autonomous navigation stack for a Quadcopter. Referenced projects and the several others not referenced directly but have similar context use only GUI. As known, despite being a moderately skilled one, MoveIt! GUI is there for just testing purposes. For those who seek industrial applications with a really complex architecture (e.g. several drones as swarms or teams, with image processing or machine learning modules), usage of code API is the inevitable task to consider. In that sense, this project possesses quite a big potential and aims to have a frontier role. Any who interested is greatly welcomed to contribute!
Exploration version 2 is explained in further detail in the Development log. In summary, missions that were postponed into this version are implemented except one particular mission. According to the log, orientation fixation and trajectory action is succesfully implemented. Only task delayed to version 3 is the grid approach. Also, a very simple metrics is devised to quantify the success of the stack itself. Initial statistics are outlined in this comment. They are very important and will provide the basis for enhancements on version 3.
In this version, the last proposed feature is implemented, i.e. there is a grid heuristics in which the drone does not navigate back into the cells that it previously visited. I have observed an inversely linear relation between the grid size and exploration percentage in 10 minutes. For example, for a 25x25 grid, the exploration rate was at most 32% whereas, in 15x15 case it boosted up to 37% degrees. In the final case, 13x13 grid allowed the drone to explore 40.7% of the volume in 10 minutes. With much more advanced heuristics, it is possible to increase this number.
Consequently, a new RViz panel for Exploration stack is developed in which the grid can be interactively inspected and the exploration rate can be observed. In future, there might be some user interface logic for particular areas to be investigated, but in the foreseeable future it is not on the To-Do list.
In order to welcome newcomers, status quo of simulation is the best advertisement. For further detail, go to Development log.
It has officially started! I will try to implement a ROS node that detects and collects valuable information (centers in 3D WCS, their dimensions) of trees and fruits. Current candidate is YOLO. I aim to produce a custom dataset consisting of snapshots from simulation view.
ROS Quadrotor Simulator by Wil Selby
Autonomous Flight by Alessio Tonioni
Darknet Retraining with Custom Dataset by Riccardo Grin
Note: If you know other similar projects that have the same context with the proposed ability, please inform me so that I can list them as a reference.