Freespace planner: requirements to work properly with parking lot and lanelet

[tseco15]

Hi,
We need to work with a long parking lot using the freespace planner in order to allow the vehicle to move forward and backwards in that area.

We experienced some issues when the vehicle changes from lanelet to parking lot, from parking lot to lanelet and even when moving inside the parking lot.

We have some uncertainties about the requirements to work in this area:

• Is it mandatory a lanelet along all the parking lot? Or is it enough with only an small overlapping area (as in our map)?
• Is there any maximum distance to send a goal in the parking lot from a position in the lanelet?

Any other considertanions of the osm building process or any other restrictions that we are not considering would be very helpful.

Thanks in advance!

[tseco15]

@kosuke55

Could you help with this question?

I would like to add a new question:

• It seems mandatory a lanelet in the map in order for the mission planner to provide a route. Is it right?

[takayuki5168]

@soblin will work on this issue.

[mkquda]

@tseco15

I apologize for the late response. I would like to provide some info regarding your query:

General Points

• Note that the free space planner is an under-developed feature, and the design requirements / specifications are not clearly set
• As of now, the free space planner is not intended to be used in the manner that you presented above (with only small overlapping area), it is expected to have a lanelet along the parking lot
• It is necessary for the map to have lanelets other wise mission planner will fail to find a route (even when operating with free space)

Other considerations

Case 1: start & goal are with parking space

• planner should be able to find a path from start to goal as long as the goal pose lies within the occupancy grid boundaries (by a margin), as shown in the image below
  

Case 2: start pose is out of parking space

• mission planner will find a route from start to the lanelet closest to the goal
• if the lanelet closest to the goal is not within parking space, once the ego reaches the end of the route, it will fail to find a path to goal
• see the images below for clarification (in the first image, end of route is out of parking space, so planner will fail to reach goal)
  
  

[tseco15]

Thank you very much for your answer. We will take your comments into consideration in our use case.

[liuXinGangChina]

Hi, We need to work with a long parking lot using the freespace planner in order to allow the vehicle to move forward and backwards in that area.

We experienced some issues when the vehicle changes from lanelet to parking lot, from parking lot to lanelet and even when moving inside the parking lot.

We have some uncertainties about the requirements to work in this area:

* Is it mandatory a lanelet along all the parking lot? Or is it enough with only an small overlapping area (as in our map)?

* Is there any maximum distance to send a goal in the parking lot from a position in the lanelet?

Any other considertanions of the osm building process or any other restrictions that we are not considering would be very helpful.

Thanks in advance!

to be honest your scenario is quite different from L4 AD vehicle, your scenario is a standard indoor service robot path-planning
1.yes parking lot which you want the robot march must have overlap with laneline（vector map）
2.no it seems no max-distance for that，path plan works with 2 condition：1 vectormap have overlay with that parking area 2 the area outside parking lot is covered with vectormap

[tseco15]

Thank you very much for your comments. We will try to adapt our scneario to a more adequate one for a L4 AD vehicle

[armaganarsln]

If you have time we will be happy if you could test the performance at AWSIM Labs. Here is one such example: autowarefoundation/autoware.universe#8342 If you have issues with AWSIM feel free to create a discussion.

[tseco15]

Hi again,
Taking all of your comments into consideration, we managed to execute a parking maneuver properly. After that, the vehicle manages to comeback to the lanelet, but if we send a goal in the lanelet again, the trajectory is planned but the vehicle does not move.

However, if we send a goal out of the boundaries of the lanelet (inside the parking lot), the vehicles reaches the goal again.

As a summary:

• From current position in the lanelet to goal position in parking lot (pos1) --> ok

• From that position to a goal position placed again in the lanelet (pos2) --> ok
  

• From that last position (pos2 ) to any other goal in the lanelet (pos3) --> the trajectory is planned but when we press the auto button, the vehicle remains stopped. The current_scenario field in /planning/scenario_planning/scenario topic is LaneDriving

• From pos2 to any other goal in the parking_lot outside the lanelet (pos4) --> ok

Any suggestions?

Thanks in advance

[tseco15]

After some tests, we discovered the issue.

The mpc lateral control returns a non-converged steering angle that avoids the vehicle to start moving. But the cause of this error is not the steering convergence but a trajectory shape change (isTrajectoryShapeChanged returns false).

We need to dig deeper into this to see if we can find the reason.
Any suggestion would be very welcome.
Thanks in advance.

[tseco15]

Just for information. We found the cause of the issue previously described.
We were testing all the parking operation in simulation before test them with the real vehicle.
The free_space_planner publishes the trajectory using the system clock:

free_space_planner_node_125

free_space_planner_node_189

Working in simultion, the clock used by the rest of autoware nodes is the simulation clock (use_sim_time true). Therefore, as the mpc controller waits for a while to propagate the trajectory shape to the output command when the trajectory shape is changed, and the trajectory_buffer is never reset (and the duration_time criteria is never met here) , the vehicle never starts its movement.

In order to solve this issue, we have modified localy the free_space_planner code to publish the node clock.

Perhanps, this modificatin should be taken into account for future free_space_planner versions.
What do you think @armaganarsln ?

[armaganarsln]

Thank you for your comment but I am not fully involved with freespace planner. @mkquda is developing. I am interested in AWSIM testing of the freespace planner and since you are not using AWSIM Labs I can't answer your question.

[tseco15]

Thank you anyway. I will try to test AWSIM also.

@mkquda , what do you think about the clock used to publish the parking trajectory?

[mkquda]

@tseco15

Thank you for investigating the issue. You are right, freespace planner should publish using the node clock instead of system clock, similar to other nodes.