search

PX4 / PX4-Avoidance

PX4 avoidance ROS node for obstacle detection and avoidance.
http://px4.io
BSD 3-Clause "New" or "Revised" License
638 stars 332 forks source link

I want to contribute #670

Open brunopinto900 opened 2 years ago

brunopinto900 commented 2 years ago

Hello,

I would like to contribute to this repository since i am very interested in motion planning for drones. I read the issues and seems like the global planner hasn't been tested properly. What is the current state of the global planner and how can i help you? I was thinking of implementing RRT with an ESDF and smooth the path with a B-spline.

brunopinto900 commented 2 years ago

@Jaeyoung-Lim Hey i used the pull request from #453 to finish the implementation of RRT and this is the result. There are still things to do before doing a pull request.

image

Jaeyoung-Lim commented 2 years ago

@brunopinto900 Great, what did you add to the pull request?

brunopinto900 commented 2 years ago

Not much, most of work was already done. The bounds are now based on goal and current location. Created a small state machine to only plan when a goal is available or when it is requested, as well as, small modifications to make it work. By the way do you have any idea to inflate obstacles in Octomap? The path given by RRT is very close to the obstacles.

The next step (after the pull request) is to use the package from ETH, the mav trajectory generation.

brunopinto900 commented 2 years ago

@Jaeyoung-Lim i would like some insight on this, if you have the time.

Jaeyoung-Lim commented 2 years ago

@brunopinto900 I think we can further discuss with the code if you can make a PR

I think it is better to do this step by step so that we can review the code incrementally rather than trying to fit in all the bells and whistles in one big change.

On the mav_trajectory_generation I think is not really relevant for now since the map representation is a octomap which has no gradient and therefore is not a good map representation for such gradient based trajectory optimization frameworks. Whether if we want something like an ESDF map depends on how reliable we can be, since the method is prone to local minimas and needs a lot of engineering to be reliable. I think probably that should not be part of this PR and we can already start using ompl as part of this framework

brunopinto900 commented 2 years ago

Hello @Jaeyoung-Lim I will finish the pull request by the end of the week. Then its Open for review and discussion.

brunopinto900 commented 2 years ago

@Jaeyoung-Lim Regarding minimum snap. There is no need for gradient based trajectory optimization. We can follow the approach by [1] "If a particular trajectory segment is found to intersect an obstacle after optimization, an additional waypoint is simply added halfway between its two ends, splitting this segment into two. This midpoint is known to be collision-free because it lies on the optimal piecewise-linear path returned by the search algorithm. "

In that paper they use Minimum Snap, RRT* and Octomap.

What do you think?

[1] Polynomial Trajectory Planning for Aggressive Quadrotor Flight in Dense Indoor Environments by Charles Richter, Adam Bry, and Nicholas Roy

Jaeyoung-Lim commented 2 years ago

@brunopinto900 In principle yes, but I would like to move towards ESDF since it provides better path moving forward.

However, the bigger problem is not the optimal planning framework (we already understand very well what we want), but rather integrating the infrastructure for PX4 which is not straight forward.

We can always improve the planning part after we have sorted the PX4 part out.

brunopinto900 commented 2 years ago

@Jaeyoung-Lim We are on the same boat then, because i want to move torwards ESDF. So the goal now is to finish the pull request. After that we shall discuss the further details.

brunopinto900 commented 2 years ago

@Jaeyoung-Lim I did the PR. In the meanwhile, what things can i do? Think about the ESDF?

Do you want to use voxblox or use code from FastPlanner https://github.com/HKUST-Aerial-Robotics/Fast-Planner ?

Thank you.

Jaeyoung-Lim commented 2 years ago

@brunopinto900 Thanks for the PR!

I think the next step would be trying to make the planner work in mission mode with OMPL before we move on to a different map representation or planner

brunopinto900 commented 2 years ago

@Jaeyoung-Lim I am not familiar with mission mode. What modifications are necessary to make it work in mission mode?

Jaeyoung-Lim commented 2 years ago

@brunopinto900 We need to get the planner to work with this interface: https://docs.px4.io/master/en/computer_vision/path_planning_interface.html , which is made so that such planner can work with mission mode

Do you have a vehicle to test the current implementation?

brunopinto900 commented 2 years ago

Ah i see. Unfortunely i don't have a vehicle (only in the summer).

brunopinto900 commented 2 years ago

@brunopinto900 We need to get the planner to work with this interface: https://docs.px4.io/master/en/computer_vision/path_planning_interface.html , which is made so that such planner can work with mission mode

@Jaeyoung-Lim Can you point some where this is done on the code? Although i understand the concept of mission mode i would like some pointers and see where it is in the code.

brunopinto900 commented 2 years ago

@Jaeyoung-Lim Regarding the implementation of the state machine for the RRT planner, which is specially important in mission mode. Why did the PR #506 didn't went through? How reasonable is to port this PR into the RRT planner?

Another question, if we decide to use a different controller rather than PX4 Pos controller, like for example your mavros_controller repo, is it easy to integrate the state machine & waypoint generator with Mavros_controller?

Thank you.