The aim of the motion planning subsystem is to calculate the motion of Quadcopter in 3D.
This task of motion planning is subdivided into the following sub-parts:
Global Path/Motion Planner
Given an Octomap, start position, and goal position, we need to calculate the ideal trajectory that the drone should follow to reach the goal. This trajectory would be planned before the drone starts its mission. Note that this is an ideal trajectory that is most probably going to change due to unpredicted obstacles in the way, inaccuracies in the initial map, and drone slightly deviating from its path while maneuvering. Hence, the need for a Local Motion Planner arises.
Local Motion Planner
The Local Motion Planner would receive
The current state of Drone from the State Estimation Subsystem.
The ideally desired path from Global Path Planner.
Local Octomap from Visual Perception Subsystem.
and then, based on the surroundings and deviation from the ideal path, it should be able to recalculate its trajectory as well as motion.
Surveying Unknown Environments
Since we also want to survey unknown environments to generate the maps for the first time, we need to work on a surveying algorithm as well for unknown environments. There has been really good work by HKUST in this field. Fast Planner and FUEL are some of the examples that we were looking to test. Needless to say, these might also be useful in understanding more about how to go about for Local Planner.
Sending Commands to Bot
The commands generated by Local Motion Planner need to be converted into ones that are understandable by the PX4 and then can be sent over to the bot. For this MAVROS is to be used.
Current Progress
Since it's a bit difficult to code up everything by hand, and we don't want to reinvent the wheel, We are in the process of trying out MoveIt! for Global Planner.
MoveIt! already has abstract 3D planners, collision checking algos, etc. implemented in the context of robots (robotic arms to be precise). We can just drop the URDF of our bot in it, give it our world's Octomap and specify algo with which we want to calculate the trajectory/motion.
As we were trying out MoveIt! we realized that we need the URDF (Unified Robot Description Format) of our bot to move any further, but we have only SDF (Simulation Description Format) for now (as it was being used in the gazebo).
And hence, the next immediate step is to convert the SDF into URDF (which mostly needs to be done manually).
For MoveIt! the implementation we are referring to is Wil Selby 3D Mapping and Navigation on Drone using MoveIt!
The mapping part is a very important aspect too. Using point cloud we were able to generate Octomaps on-the-go. But with the use of the RTAB-Map package, that package is going to take care of this and we don't have to deal with this manually anymore.
Thoughts on Local Planner
The receding horizon controller with dynamic window approach looks promising but there's time till we get there. FAST and FUEL probably use this approach too.
The maps generated by Local Planner should also be merged with existing maps so as to increase their accuracy over time.
Other stuff
Sampling-based Algorithms looked better for our use case.
MoveIt! was easier to use and advance than ROS Navigation for 3D Navigation.
Octomaps are an efficient way to store 3D worlds. They are based on Octrees.
Behavioural Planner needs to be implemented too, to take into account the predicted trajectory of moving obstacles by Visual Perception Subsystem.
For Model Predictive Controller and the Receding horizon Controller for Local Planner a good starting point will be to refer to Research Papers by Kostas Alexis
The aim of the motion planning subsystem is to calculate the motion of Quadcopter in 3D. This task of motion planning is subdivided into the following sub-parts:
Global Path/Motion Planner
Given an Octomap, start position, and goal position, we need to calculate the ideal trajectory that the drone should follow to reach the goal. This trajectory would be planned before the drone starts its mission. Note that this is an ideal trajectory that is most probably going to change due to unpredicted obstacles in the way, inaccuracies in the initial map, and drone slightly deviating from its path while maneuvering. Hence, the need for a Local Motion Planner arises.
Local Motion Planner
The Local Motion Planner would receive
and then, based on the surroundings and deviation from the ideal path, it should be able to recalculate its trajectory as well as motion.
Surveying Unknown Environments
Since we also want to survey unknown environments to generate the maps for the first time, we need to work on a surveying algorithm as well for unknown environments. There has been really good work by HKUST in this field. Fast Planner and FUEL are some of the examples that we were looking to test. Needless to say, these might also be useful in understanding more about how to go about for Local Planner.
Sending Commands to Bot
The commands generated by Local Motion Planner need to be converted into ones that are understandable by the PX4 and then can be sent over to the bot. For this MAVROS is to be used.
Current Progress
Since it's a bit difficult to code up everything by hand, and we don't want to reinvent the wheel, We are in the process of trying out MoveIt! for Global Planner. MoveIt! already has abstract 3D planners, collision checking algos, etc. implemented in the context of robots (robotic arms to be precise). We can just drop the URDF of our bot in it, give it our world's Octomap and specify algo with which we want to calculate the trajectory/motion.
As we were trying out MoveIt! we realized that we need the URDF (Unified Robot Description Format) of our bot to move any further, but we have only SDF (Simulation Description Format) for now (as it was being used in the gazebo). And hence, the next immediate step is to convert the SDF into URDF (which mostly needs to be done manually). For MoveIt! the implementation we are referring to is Wil Selby 3D Mapping and Navigation on Drone using MoveIt!
The mapping part is a very important aspect too. Using point cloud we were able to generate Octomaps on-the-go. But with the use of the RTAB-Map package, that package is going to take care of this and we don't have to deal with this manually anymore.
Thoughts on Local Planner
Other stuff