This issue will help not only the State Estimation subsystem but also the Motion Planning subsystem. I will cover the State Estimation aspect of the issue here.
First, head over to this link and read the short article to understand what State Estimation means and why it is important.
You are encouraged to read this wonderful roadmap prepared by Mehul.
From the doc you just read, we might not need Gmapping, SLAM Toolbox, Google Cartographer, Navigator 2, or Hector SLAM. So there is no need to explore these immediately for the quadcopter project. One of the most important takeaways from it, though, is that you WILL HAVE to learn C++. All the SLAM packages are written in C++, and for understanding the code as well as modifying it later, we will need good C++ skills.
What we have done so for:-
Till now, we have explored a lot of algorithms for State Estimation. You can read about Kalman Filter, Extended Kalman Filter (EKF), Unscented Kalman Filter (UKF), Particle Filter (PF), etc. We will obviously provide resources for these, but more on that later.
We had earlier tried to implement a combination of EKF and PF by scratch, but seeing the huge challenges beyond coding the basic algorithm, we have now decided to use the existing SOTA packages built for this.
We are currently exploring the fusion of RTAB-Map and the robot_localization package. RTAB-Map has a localization stack which we will use for this purpose. robot_localization has two algorithms, EKF and UKF. We will be using EKF as it is computationally less expensive and provides almost equal estimates as compared to UKF. We might also use the AMCL package with this combination. After testing each algorithm individually and their fusion, we will think about the potential modifications to the codes to improve the state estimates.
What we are planning to do next:-
Now coming to the immediate subtask for the subsystem. This subtask will be of great help to not only the State Estimation Subsystem but also the Motion Planning Subsystem.
Our current quadcopter model, i.e. a modified version of the if750a has been written as a .sdf file. We need a .urdf file of the same, as only the .urdf file type is compatible with some of the packages we have chosen to use.
One can easily convert a urdf file to a sdf file using gz sdf -p MODEL_URDF.urdf > MODEL_SDF.sdf. Unfortunately, one cannot go the other way round. So you will have to convert each line of the sdf file into the urdf compatible syntax. Once you have converted one part of the sdf file to urdf (e.g., some link, or some joint, etc.), you can check if the conversion is valid by running gz sdf -p MODEL.urdf. The output of this command should be the same as the corresponding code from your sdf file.
You can find a lot of tutorials on Gazebo’s and ROS's site. These will help you understand how to write the urdf and sdf files. Googling will go a looong way.
You can even find a partially completed urdf file in the repository. Your job is to complete that implementation and make a working .urdf file of the robot.
After that, we will be able to use robot_localization and MoveIt! (a package for motion planning) on our quadcopter. More details will be provided on how that can be done after the completion of this subtask.
Brief Info:-
This issue will help not only the State Estimation subsystem but also the Motion Planning subsystem. I will cover the State Estimation aspect of the issue here.
First, head over to this link and read the short article to understand what State Estimation means and why it is important.
You are encouraged to read this wonderful roadmap prepared by Mehul.
From the doc you just read, we might not need Gmapping, SLAM Toolbox, Google Cartographer, Navigator 2, or Hector SLAM. So there is no need to explore these immediately for the quadcopter project. One of the most important takeaways from it, though, is that you WILL HAVE to learn C++. All the SLAM packages are written in C++, and for understanding the code as well as modifying it later, we will need good C++ skills.
What we have done so for:-
What we are planning to do next:-
Now coming to the immediate subtask for the subsystem. This subtask will be of great help to not only the State Estimation Subsystem but also the Motion Planning Subsystem.
gz sdf -p MODEL_URDF.urdf > MODEL_SDF.sdf. Unfortunately, one cannot go the other way round. So you will have to convert each line of the sdf file into the urdf compatible syntax. Once you have converted one part of the sdf file to urdf (e.g., some link, or some joint, etc.), you can check if the conversion is valid by runninggz sdf -p MODEL.urdf. The output of this command should be the same as the corresponding code from your sdf file.After that, we will be able to use robot_localization and MoveIt! (a package for motion planning) on our quadcopter. More details will be provided on how that can be done after the completion of this subtask.