what if function "IfInitialCubeFree()" failed?

[Ivesss]

During the middle of planning, one of the initial cube generated by seed(i) and seed(i+1) failed(i.e the initial rectangle cube generated overlap with dynamic obstacle), what would happen next?

The following GetDir and Inflation process can not proceed if the initial cube has failed, do we go back and regenerate the WHOLE set of seed and run again? Thanks!

[Ivesss]

Seems to me that, although the initial cube is not free, but that seed and its surrounding is collision free, can we connect this two seeds and initialize the cube by a polygon(not exactly a rectangle formed by seed(i) and seed(i+1) as two vertices)

[WenchaoDing]

Thanks for your question! Let me answer your question one by one.

First, what will happen if the initial cube formed by the two consecutive seeds is not free? Actually, in the paper, we already discuss and justify this situation: (Section V. B)

Since the forward simulated states are discretized, the feasibility of the corridor generation process depends on the complexity of environments and seed resolution. To guarantee the success of the corridor generation process, we require the initial cubes constructed from consecutive seeds to be collision-free (Fig. 4 (a) and Line 6, Algo. 2). In practice, this clearance requirement is reasonable and easy to achieve. For example, for a vehicle travelling at a longitudinal speed of 30 m/s and a seed resolution of 0.15 s (similar to [16]), the clearance required is roughly 4.5 m, which is much shorter than the emergency braking distance at such a high speed. Therefore, it is reasonable to directly reject the cases which violate the proposed requirement.

Second, what about using polygon? This is doable. However, for ground vehicles, we usually consider the lateral and longitudinal movements. So we consider the axis-aligned cubes in the longitudinal-lateral-time domain as the most typical and natural representation. You can also try with the polygon representation which may bring in slightly more feasibility. But we do not expect too much improvement by doing this. Actually, in our experiments, we find the cube representation already very flexible while being highly efficient.

[Ivesss]

@WenchaoDing Thank you for the response. Basically if the initial cube failed, the trajectory itself is just not a feasible one.

I went over the paper and the released code again recently, I found out many source functions(i.e. one important piece: GetBezierSplineUsingCorridor()), and the 'detailed calculation of Q' were missing. . I'm wondering when would the rest code being released? Or at least could you guild me about how to get the Q matrix in the quadratic form please, in that case I could try to solve it my self.

Thank you!

[WenchaoDing]

@Ivesss Sure! These functions will all be released. Actually, the whole platform including the simulator, mpdm behavior planner, route planner and other common functions are all going to be released.

[WenchaoDing]

Keep an eye on this!

The dependencies of this project includes (comming soon): common package: an integration of various mathematical tools such as polynomial, spline, primitive, lane, trajectory, state, optimization solvers, etc. It provides many easy-to-use interfaces for mathematical modeling. phy_simulator package: a configurable multi-agent simulator. It provides ground truth information and listens planner feedbacks. semantic_map_manager package: map with semantic information for vehicle local planning. Each agent is capable of rendering its local planning map based on its configuration. vehicle_model package: basic vehicle models and controllers. vehicle_msgs package: ros communication messages and corresponding encoder and decoders. playgrounds package: test cases/configurations/scenarios stored in json format. behavior_planner package: mpdm behavior planner for on-road driving. It can provide a local reference lane based on navigation information and behavior decision. forward_simulator package: forward simulation motion_predictor package: surrounding vehicle motion prediction. route_planner package: road-level route planner, a simple version. The dependencies will be released in another repo: https://github.com/HKUST-Aerial-Robotics/HDJI_planning_core.

This repo will be accessible when we finish the refactoring.

[Ivesss]

@WenchaoDing Thank you for the quick response. I will certainly keep eye on that repo.

I have another question. During the optimization process, for the j-th segment of the whole bezier curve, we piecewise it into [t0,t1], [t1,t2]....[tn-1,tn], and each time frame is another small bezier curve. When imposing 'free-space constraints', for example we checking every 2 sec([t0,t2], [t2,t4]...), how do you constraint every single point on that bezier curve is within the corresponding cube for every time fame?

For example for t = [t0, t2], cube_low <= s(t) <= cube_upper. I imagine you would splice t into t=0,0.5, 1, 1.5, 2. But then in this case, how do you ensure the points in between are feasible, like when t=0.2, 0.3, 0.7, 1.7...?

Thank you!

[WenchaoDing]

@Ivesss Thanks for your response. The free-space constraint is not enforced in a sampled manner like what traditional motion planners do. We utilize the convex hull property of Bezier curve to ensure the entire segment is collision free. Basically, for each semantic cube, if the control points of the Bezier curve are confined inside the cube, the resulting entire segment will be collision free.

[LiJiangnanBit]

Keep an eye on this!

The dependencies of this project includes (comming soon): common package: an integration of various mathematical tools such as polynomial, spline, primitive, lane, trajectory, state, optimization solvers, etc. It provides many easy-to-use interfaces for mathematical modeling. phy_simulator package: a configurable multi-agent simulator. It provides ground truth information and listens planner feedbacks. semantic_map_manager package: map with semantic information for vehicle local planning. Each agent is capable of rendering its local planning map based on its configuration. vehicle_model package: basic vehicle models and controllers. vehicle_msgs package: ros communication messages and corresponding encoder and decoders. playgrounds package: test cases/configurations/scenarios stored in json format. behavior_planner package: mpdm behavior planner for on-road driving. It can provide a local reference lane based on navigation information and behavior decision. forward_simulator package: forward simulation motion_predictor package: surrounding vehicle motion prediction. route_planner package: road-level route planner, a simple version. The dependencies will be released in another repo: https://github.com/HKUST-Aerial-Robotics/HDJI_planning_core.

This repo will be accessible when we finish the refactoring.

@WenchaoDing 请问这些包还会放出来吗？尤其想了解MPDM决策是如何实现的。谢谢！

[l2411076]

@WenchaoDing hello Wenchao Ding, when i catkin_make the ssc_planner node.i found the dependencies of this project not exist,in this page https://github.com/HKUST-Aerial-Robotics/HDJI_planning_core.

[MasterIzumi]

@l2411076 Thanks for your response. We are still improving and polishing the whole framework and also adding some new features. I think the dependencies and a playable demo will be released after finishing our current work. (maybe 1~2 months later if we have bandwidth :) )

[MasterIzumi]

@LiJiangnanBit

会的，我们还在整理这块的代码。近期手头上还有一些别的工作，完成后我们会开源包括仿真环境、行为决策等模块的代码。

Yes, we are still refactoring and improving the code. The dependencies will be released after finishing our current work, including a lightweight simulator, a decision-making module (https://github.com/HKUST-Aerial-Robotics/eudm_planner) and etc.

[WenchaoDing]

For those who want to build the whole project, you may refer to "https://github.com/HKUST-Aerial-Robotics/EPSILON". We are trying to add some guidelines in readme to help you build it easily.