zju-fast-lab / gcopter Goto Github PK

Dear Dr Wang,

GCopter is an amazing traj opt framework that allows efficient opt of control points and knot placements simultaneously.
Your wonderful thesis gives detailed explanation of gcopter and its applications.

Can you share 'fast iterative region inflation for corridor generation' paper link?

I've been compiling your code in C++17 and added -fsanitize=address,undefined in debug mode to check some errors.

The executable compiled in debug mode complained of a runtime error (store to misaligned address for type 'double', which requires 8 byte alignment) around

Really wonderful job in back-end！But i can not figure out what method the sfc_gen.hpp adopt. It is difficult to read the code without reference.
Thank you in advance.

Hi there! I was compiling some code in C++17 that uses the GCOPTER headers for a current research project, and noticed 2 compilation errors that I figured I'd bring up:

1. gcopter.hpp uses methods in the geo_utils namespace, but doesn't directly or indirectly #include "geo_utils.hpp". Adding the include seemed to fix the problem.
2. The filterLess struct operator() function in geo_utils.hpp isn't const. Changing the function header to the following allowed me to compile successfully:
   inline bool operator()(const Eigen::Vector3d &l, const Eigen::Vector3d &r) const;

Thanks for sharing this framework, it's very nicely done!

hello! I take care of you work with long time.I have some questions.I would like to know this work and you ego-planner are two different works in trajectory planning?I can use GCOPTER as a black box?thank you very much

I want to run it on an omniwheel robot

Why does the Code link in "Multicopter Swarms Planning: youtube or bilibili. (Reported by IEEE Spectrum Website!) Code" not point to the code of the paper in the video, but to ego planner v2?
Where is the open source code for this article 《Decentralized Spatial-Temporal Trajectory Planning for Multicopter Swarms》 which commits that "The software will be released after the reception of our previous work(GCOPTER) for the reference of the community" ?
Thanks !

Hi, Zhepei, thanks for your excellent work. A little question about the elimination of the constraints. it seems that the backward and forward of T and P (in gcopter.hpp) are not the same as described in the paper. I understand that the way it is implemented can also do the elimination of the constraints. Or am I just wrong and the implementation in the code is actually exactly the same as in the paper?

Hi, when i use the code, after setting the goal point, the code report the error, is there a solution for this ?
terminate called after throwing an instance of 'ompl::Exception'
what(): Direct sampling of the path-length objective requires Eigen, but this version of OMPL was compiled without Eigen support. If possible, please install Eigen and recompile OMPL. If this is not possible, you can manually create an instantiation of RejectionInfSampler to approximate the behaviour of direct informed sampling.

Hi.
Firstly, I really appreciate for sharing your great works.
I wonder which controller you used for tracking planned trajectory accurately.
I looked into some of your lab's papers mentioning MINCO but couldn't find which controller you used for real-world drones.
Even though the trajectory planned is dynamics-awared, I believe that controller should be also very accurate and fast, with feedback of course.

I also wonder when you are planning to provide further example codes, especially for the ball-shaped corridor safety constraints!

Thank you in advance.

hello! I want to ask that do you like to publish the source of Formation Keeping Planning? wether you have the test in real UAV?
Thanks for your answer!

It is exciting to see your excellent work. From the source code, I want to know how to add the waypoint and the attitude for the quadrotor in the waypoint except for the starting point and end point, which makes the quadrotor flying through the given waypoint at the desired atttiude and yaw angle.

Looking for your reply and thanks a lot.

I learned the planning method at the control level in the flatness.pdf of this project. However, the flatness.cpp lacks important parameters, such as moment of inertia, etc. I want to know if these parameters are intentionally ignored or if they are nested as constants in the code. If so, how can I manually input these variables. Thanks.

terminate called after throwing an instance of 'ompl::Exception'
what(): Direct sampling of the path-length objective requires Eigen, but this version of OMPL was compiled without Eigen support. If possible, please install Eigen and recompile OMPL. If this is not possible, you can manually create an instantiation of RejectionInfSampler to approximate the behaviour of direct informed sampling.

Dear Dr Wang,

GCopter is an amazing traj opt framework that allows efficient opt of control points and knot placements simultaneously.
Your wonderful thesis gives detailed explanation of gcopter and its applications.
I'd like to learn more about the minco traj representation, esp. regarding its comparison to the traditional b-splines.
The below pics are from your thesis,

There are two points that are baffling to me.

1. Why do the spatial temporal parameters of B-splines highly coupled compared to Bezier curves and MINCO?
   for instance, for the 4th order B spline, p(t) = f(c_i-3, c_i-2, c_i-1, c_i, t_i-3, t_i-2, t_i-1, t_i, t_i+1, t_i+2, t_i+3, t_i+4, t), where t is in [t_i, t_i+1), ie, p(t) = f(c_i-3, c_i-2, c_i-1, c_i, T_i-3, T_i-2, T_i-1, T_i, T_i+1, T_i+2, T_i+3, T_i+4, t - t_i), where T_i = t_i - t_i-1.
   Therefore, for a constraint W(c, T), we can efficiently compute its derivatives relative to the control points c_i and the time segments T_i by taking advantage of the B splines' local support property.
   The derivative computation for the B splines apparently is less involved than the derivations given in your thesis, eg, eq 3-84 and 3-93.
   Let's look at eq 3-93. The main complexity comes from G_i which is from solving M G = dK/dc.
   I think solving this equation causes G_i to be dependent on time segments other than T_i, may be all the way from T_1 to T_M.
   In contrast, the derivative of a B spline relative to time is only dependent on finite time segments, 8 for the above 4th order case, T_i-3, up to T_i+4.
   In this sense, the spatial temporal coupling of MINCO is higher than B-splines.
   Please correct me if I am wrong. I know that often times I am wrong.

2. What is exactly the 凸包保守度？I know that B splines enjoy the convex hull property as explained in the ego planner paper, but the conservativeness of the convex hull sounds hard to understand to me.

Hi, I've been doing experiments based on this repo. I've learned to generate a series of convex hulls from your code is basically writing the code like this

std::vector<Eigen::Vector3d> pc;
VOXEL_MAP.getSurf(pc);
std::vector<Eigen::MatrixX4d> h_polys;
sfc_gen::convexCover(route, pc, 
                      VOXEL_MAP.getOrigin(), 
                      VOXEL_MAP.getCorner(), 
                      2.0, 2.0, h_polys);
sfc_gen::shortCut(h_polys);

I intend to use your code in my project to generate convex hulls, but it seems complicated for me to get around generating fixed-row matrices of convex hulls e.g., std::vector<Eigen::Matrix<double, 10, 4>>.

I know that in order to best achieve the max space of the safe flight corridor, the convex hull matrix should be dynamic in rows. But as in my project, I need to specify a fixed number of rows. Is there any way that I can achieve this goal?

Thanks.

Where are the start-up items for Formation Hold and Multicopter Swarms Planning?

@ZhepeiWang Thanks a lot. I found some associted code about gcopter at https://github.com/ZJU-FAST-Lab/Fast-Racing/blob/a1d086ccb6deb2993d71a5afda13fffa66567363/src/plan_manage/src/MinCoPlan_CPU.cpp#L117 - https://github.com/ZJU-FAST-Lab/Fast-Racing/blob/a1d086ccb6deb2993d71a5afda13fffa66567363/src/plan_manage/src/MinCoPlan_CPU.cpp#L124.

It is a huge project, which may be unfriendly to the newer. Could you share some ideas about how to show the large tilt angle
to crosse narrow gaps, and how to insert the waypoints in the #9 (Adding the waypoints)?

Thanks again, and wish your reply!

Recently I read your code about generating the shortcut SFC, and I found this line is kind of confusing. Maybe it should be "i= j;"?, or could you explain the reason why it should be "i = j+1"?
In my understanding, when you find two polyhedrons that connect to each other, you should keep the newly connected polyhedron as the short SFC's tail and find another polyhedron to connect to it (but not choose the former polyhedron as the SFC tail).

The following error occers when I use the 2D nav goal button to set the target destination, why? any solutions? thanks!

terminate called after throwing an instance of 'ompl::Exception'
what(): Direct sampling of the path-length objective requires Eigen, but this version of OMPL was compiled without Eigen support. If possible, please install Eigen and recompile OMPL. If this is not possible, you can manually create an instantiation of RejectionInfSampler to approximate the behaviour of direct informed sampling.
[global_planning_node-5] process has died [pid 18379, exit code -6, cmd /home/nuc/ROS/devel/lib/gcopter/global_planning __name:=global_planning_node __log:=/home/nuc/.ros/log/cca85ec0-befa-11ec-b074-38fc989acd2e/global_planning_node-5.log].
log file: /home/nuc/.ros/log/cca85ec0-befa-11ec-b074-38fc989acd2e/global_planning_node-5*.log

The quadrotor is required to fly through the windows, but based on the gcopter planning, it bypass the wall to the endpoint. Thus, what's wrong the the trajectory planner? how to get the desired path?

The video can be found here

Wish your reply and thank you very much!

Test platform: Nvidia Orin NX, Ubuntu 20.04.
The polyhedra is illegally visualized.

However, when changing the "gcopter/quickhull.hpp" to the original quickhull: https://github.com/akuukka/quickhull, bugs finished.

Thanks for your great job! I have a question on FlatnessMap. In your paper, it is noted that no assumption is made on concrete forms and more accurate dynamics such as the rotor drag can be adapted to fully exploit physical limits. However, in the code of class FlatnessMap, I've found drag coefficients including horizontal, vertical, and parasitic ones. Are they required mandatorily? And how to calibrate these parameters on a real drone? Thank you!

大佬可以点一下子吗，这里不知道是用了什么方法，符号和论文里面对应不起来，几句话稍微点一下子就行

Hi, when i use the code in our own environment, the code always meets the error in the part of convexCover if there are no obstacles info around the route. Is there a bug in the code or just caused by our incorrect using?