-
Notifications
You must be signed in to change notification settings - Fork 41
/
Copy pathApollo_issue.cpp
5069 lines (3176 loc) · 241 KB
/
Apollo_issue.cpp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1.
/*
After a destination is given, routing module produces a sequence of end to end zigzag linear segments. Obviously, such lines can't be used for path planning. So a smoothing algorithm on the routing segment is done online to get a differentiable curve, which is called reference line, for the Planning module to work on.
Don't quite understand what is your definition of passages. If you mean the smoothed reference line, then yes. As the current implementation on computing reference line is online, to save computation effort. only a definite horizon of reference line is computed each cycle, so there would be overlapped part. To deal with that, we use stitching to combine two together. Check reference_line_provider.h for more detail.
There's no "passage" in map. I guess you are referring to "passage" in routing.
You can find the definition here:
https://github.com/ApolloAuto/apollo/blob/master/modules/routing/proto/routing.proto
Basically, lanes segment < passage < road
A "passage" is a path generated based on a set of nodes/points. The algorithm can be found in
https://github.com/ApolloAuto/apollo/blob/master/modules/routing/core/result_generator.cc
There might be lane-changes inside one passage.
*/
/// https://github.com/ApolloAuto/apollo/issues/3843
Lane change is a planning option given by routing.
When there is a change lane region in routing, we will create two reference lines, one on current lane, and another on the target lane. The planning algorithm will try to make one planning trajectory on each reference line, and it will eventually select one based on traffic rules and cost functions.
The presence of obstacle does not affect how to create passage and reference line,
but the obstacles do affect the cost of driving on each reference line, then affect planning change lane.
lane change triggered by route from pnc map (This is true), or presence of obstacle on the lane (this feature not supported yet). Obstacle does not trigger change lane now, but it will affect change lane decision.
"reference line is changed" is not accurate. I would say "reference line is selected". Reference line is a static information derived from route and map. Multiple reference lines in a frame indicate that change lane is an option in the current frame. Planning selects reference line based on traffic condition and obstacles, and a lot of other logic.
// https://github.com/ApolloAuto/apollo/issues/4208
The current code flow is:
raw_reference_line -> anchor_points -> smoothed reference line.
Anchor points were designed as the middle layer, such that different smoothing algorithms can have a uniform constraint input (which is anchor point), without being bothered by how these anchor points are generated.
You may already notice that there is some logic in how to extract and shift these anchor points, and anchor points could come from a part of a previous reference line. This logic is orthogonal with the smoothing algorithm. It also allows us to generate anchor points from more resources than raw reference line, e.g., in places with out explicit lane info.
// https://github.com/ApolloAuto/apollo/issues/9434
I do not understand the ROI mentioned in the open spacel planner, what is its function?
Roi refers to "Region of Interest", describing the drivable area and target position
// https://github.com/ApolloAuto/apollo/issues/8439
Describe the bug
We are using Apollo 3.5 version and running into some issues with the planning module. After
finishing a routing request. The console on the dreamview shows "Routing Success! ". However, the "planning.INFO" tells me the routing is not ready. The consequence is that although there is a red line shows up on the map (reference_line), no planning messages are being published.
@yangydavid
if you launch planning module manually from terminal, you shall turn off planning module from DreamView, and then launch planning manually from terminal.
And, you need launch planning mode first, and then send routing request. So that planning module can receive routing response. Otherwise, when the planning module starts, the routing response was already gone. Although you can see routing red line in DreamView, the planning module actually never got it in time.
Let us know if that is the case.
// https://github.com/ApolloAuto/apollo/issues/8354
I am using Apollo 3.0.
I would like to ask the question about the usage of "PathData" in EM planner.
In the first step of EM planner-- inside "DpPolyPathOptimizer(...)", there is a function "bool DPRoadGraph::FindPathTunnel(...)" to generate the "tunnel" of "PathData path_data". The resolution of the "frenet_frame" in the tunnel is set as "path_resolution / 2".
My question is: if I use my own planner to replace "DpPolyPathOptimizer(...)" and generate this "tunnel" with a sequence of "frenet_frame"s and the distance between two neighbouring "frenet_frame"s is a not a constant value (for example, the distance between two neighbouring "frenet_frame"s fluctuates around 0.4 to 0.6), will this new PathData generated by myself with non-constant "path_resolution" be still suitable for following steps in EM planner (e.g. PathDecider, DpStSpeedOptimizer(), SpeedDecider(), QpSplineStSpeedOptimizer(), PolyStSpeedOptimizer())?
@hezudao23 path planning is independent from speed planning. So the path generated by your customized or different resolution shall still work with the speed planning algorithms followed.
BTW, in Apollo 5.0, we are not using dp_poly_path_optimizer any more.
// https://github.com/ApolloAuto/apollo/issues/8406
// according to the position of the start plan point and the reference line,
// the path trajectory intercepted from the reference line is shifted on the
// y-axis to adc.
double dest_ref_line_y = path_points[0].y();
Path trajectory intercepted from the reference line should be lateral dist which is in the Frenet
coordinate, not the path_points[0].y() which is in the Cartesian coordinate.
@xmyqsh Path trajectory generated by the relative map is in FLU coordinate which origin is at the vehicle position. And FLU coordinate is not Frenet coordinate but Cartesian coordinate.
But at the start point of Path trajectory, the FLU coordinate is coincidence with the Frenet coordinate. So, the lateral dist is the path_points[0].y() exactly.
//https://github.com/ApolloAuto/apollo/issues/7314
lattice planner中对于静止障碍物的处理似乎有一些粗糙，我看到代码中表示，如果静止障碍物在当前车道上，就直接将其映射到ST图中，因此，如果车道上最右侧有一个小箱子（正常行驶不会撞到），我们应该不予考虑，但lattice中，我们似乎无法通过它。
你说的这个问题确实是在ST上无法越过的, 但是这种情况下就变道了, 这样投影就没问题. Lattice是基于高速公路的, 你说的那种情况发生的概率很小
void PathTimeGraph::SetStaticObstacle( const Obstacle* obstacle, const std::vector<PathPoint>& discretized_ref_points) {
const Polygon2d& polygon = obstacle->PerceptionPolygon();
std::string obstacle_id = obstacle->Id();
SLBoundary sl_boundary = ComputeObstacleBoundary(polygon.GetAllVertices(), discretized_ref_points);
double left_width = FLAGS_default_reference_line_width * 0.5;
double right_width = FLAGS_default_reference_line_width * 0.5;
ptr_reference_line_info_->reference_line().GetLaneWidth(sl_boundary.start_s(), &left_width, &right_width);
if (sl_boundary.start_s() > path_range_.second || sl_boundary.end_s() < path_range_.first || sl_boundary.start_l() > left_width || sl_boundary.end_l() < -right_width) {
ADEBUG << "Obstacle [" << obstacle_id << "] is out of range.";
return;
}
path_time_obstacle_map_[obstacle_id].set_id(obstacle_id);
path_time_obstacle_map_[obstacle_id].set_bottom_left_point(SetPathTimePoint(obstacle_id, sl_boundary.start_s(), 0.0));
path_time_obstacle_map_[obstacle_id].set_bottom_right_point(SetPathTimePoint(obstacle_id, sl_boundary.start_s(), FLAGS_trajectory_time_length));
path_time_obstacle_map_[obstacle_id].set_upper_left_point(SetPathTimePoint(obstacle_id, sl_boundary.end_s(), 0.0));
path_time_obstacle_map_[obstacle_id].set_upper_right_point(SetPathTimePoint(obstacle_id, sl_boundary.end_s(), FLAGS_trajectory_time_length));
static_obs_sl_boundaries_.push_back(std::move(sl_boundary));
ADEBUG << "ST-Graph mapping static obstacle: " << obstacle_id << ", start_s : " << sl_boundary.start_s() << ", end_s : " << sl_boundary.end_s()<< ", start_l : " << sl_boundary.start_l()<< ", end_l : " << sl_boundary.end_l();
}
// https://github.com/ApolloAuto/apollo/issues/6038
planner是如何避免跟轨迹冲出道路边缘如防护栏等的？
在制作生成高精地图时，你说的护栏、道路边缘等非道路的就已经标记为不可行驶区域被排除了。另外在车辆行驶时，perception 也会实时检测这些障碍物。传到 planning时，这些都已经被标记为不可行驶区域， planning只会在可行驶区域撒点规划，自然不需要处理这些不可行驶静态障碍物的逻辑。
// https://github.com/ApolloAuto/apollo/issues/5897
apollo 3.0相对地图导航模式支持多车道超车，我们使用relative map+ lattice+navigation模式，
在对code分析中，lattice_planner.cc是在横向-0.5~0.5，纵向10m、20m、40m、80m范围根据指引线进行路径规划，也就是lattice_planner.cc是在本车道(当前指引线)进行规划吗？
lattice_planner.cc路径：
/home/alan/apollo/modules/planning/planner/lattice/lattice_planner.cc
如果前方有障碍物需要变换车道，这个时候需要临近车道的指引线给lattice_planner.cc吗？这个指引线是通过reference_line_provider.cc提供的吗？
reference_line_provider.cc地址：
/home/alan/apollo/modules/planning/reference_line/reference_line_provider.cc
即如果前方有障碍物需要换车道时是通过变换lattice_planner.cc的指引线进行的吗？
lattice指引线只有最多有两个,一个是ego lane, 还有一个是 neighbour lane , 选择哪个是通过所有的trajectory评分完毕后看分数最低的来决定的, 如果有障碍则连评分的资格都没有. lattice里面并没有去刻意判断是超车,还是跟车等等. 一切都是看评分. neighbour lane优先还是ego lane优先是通过ChangeLaneDecider类来完成基本判断的,仅仅是调整一下优先级而已
// /modules/planning/common/frame.cc. 在初始化frame类时即Frame::Init()会调用bool Frame::CreateReferenceLineInfo()，在bool ReferenceLineProvider::GetReferenceLines中从相对地图处获取reference line和segment，在获取完信息后存放在ReferenceLineInfo类指针中。同时在bool Frame::CreateReferenceLineInfo()中通过如下判断本车道优先还是临近车道优先，
if (FLAGS_enable_change_lane_decider &&
!change_lane_decider_.Apply(&reference_line_info_)) {
AERROR << "Failed to apply change lane decider";
return false;
}
但是有个问题是这儿有一个FLAGS_enable_change_lane_decider 宏，如果盖红设置为false，不进入该逻辑，那么车道优先级是车当前车道为最优优先级吗？
2. 规划模块从相对地图模块接收到reference line，然后将这些reference line存放在reference line info这个类中，用python navigatior xxxx.smothed 脚本播放轨迹，播放几个轨迹，便有几个reference line，也便有几个reference line info。然后对每一个reference line info求取车的横向和纵向规划轨迹束，在求取纵向轨迹的过程中会考虑三种情况即超车、跟车、遇到障碍物及交通信号等停车，根据每一种情况分别进行轨迹生成，生成完横向纵向轨迹然后通过评价函数选取每一对横向纵向轨迹束进行打分，
获取轨迹对评价值：
double trajectory_pair_cost =
trajectory_evaluator.top_trajectory_pair_cost();
获取轨迹：
auto trajectory_pair = trajectory_evaluator.next_top_trajectory_pair();
在对每一个reference line info进行生成轨迹束的过程中最终只会有一个最优的轨迹数据存放到reference line info中。
每一个规划周期选出最优的纵向、横向轨迹对，这些信息存放在ReferenceLineInfo 类指针中， 然后通过 FindDriveReferenceLineInfo选出代价最小的轨迹发布出去，
选出代价最小轨迹：
const auto* best_ref_info = frame_->FindDriveReferenceLineInfo();
综上：即python navigatior xxxx.smothed播放几条参考线，生成几车道的相对地图，那么规划模块就会根据每一个参考线生成一最优条轨迹(此处的轨迹不是生成横向纵向轨迹束，而是对横向纵向轨迹束合成之后的轨迹)，然后从这几条参考线的最优轨迹中选取代价小的一条进行发布出去。
// https://github.com/ApolloAuto/apollo/issues/5915
The EM can find a path (dp_poly_path) that why you see the thin "green" line, but the trajectory (thicker green line) for that path will have a collision with the obstacle, that why EM planner fails even when it found a path, in this case, path from dp_poly_path is not a good path.
In order to make EM search for a good path, you have to tune the parameters of EM (change the sample resolution, increase sample in S/L direction...), but it may increase the processing time.
by changing the parameter Step_length_min and step_length_max to 11, can the vehicle successfully pass the obstacle. according to my experiments 11 is the limit value in this case. Thank you all.
// https://github.com/ApolloAuto/apollo/issues/5739
Hi Guys,
This is with respect to issue #4008.
I have created a custom created map with 2 lanes in same direction to test the lane change and overtake behavior. Below are the details.
a) Length - 320 m
b) Lane IDs 98_1_-1 and 98_1_-2
c) right neighbor and left neighbor has been updated as well.
The autonomous vehicle still do not do the lane change behavior.Can anybody please explain me what is missing in here ?
What planner you use.
if you use the EM, tune the parameter in planning_config.pb
also in planning_gflags (look for lane change parameter)
Good luck
// https://github.com/ApolloAuto/apollo/issues/9218
// Why path_out_lane_cost is not used?
the value of "path_out_lane_cost" is huge and it was intended to "force" adc to keep in-lane. But that is not always what we really want, e.g when adc side-pass obstacles or change lanes...
and "path_l_cost" can help "keep" adc closer to reference_line, or in lane.
BTW, in Apollo 5.0, we are not using dp_poly_path_optimizer any more.
ComparableCost TrajectoryCost::CalculatePathCost() {}
// https://github.com/ApolloAuto/apollo/issues/8439
// Routing not ready
Describe the bug
We are using Apollo 3.5 version and running into some issues with the planning module. After
finishing a routing request. The console on the dreamview shows "Routing Success! ". However, the "planning.INFO" tells me the routing is not ready. The consequence is that although there is a red line shows up on the map (reference_line), no planning messages are being published.
if you launch planning module manually from terminal, you shall turn off planning module from DreamView, and then launch planning manually from terminal.
And, you need launch planning mode first, and then send routing request. So that planning module can receive routing response. Otherwise, when the planning module starts, the routing response was already gone. Although you can see routing red line in DreamView, the planning module actually never got it in time.
// https://github.com/ApolloAuto/apollo/issues/7979
// How to limit curvature of reference line
I understand that the reference line is generated from HDmap data. Is there any way to set a limit for curvature of the reference line without modifying the HDmap? Another way, how to implement the curvature constraints for the reference line?
Thank you for your reply, I changed the reference line smoother from QpSplineReferenceLineSmoother to SpiralReferenceLineSmoother. (change smoother_config_filename in the planning_gflags.cc)
The lines you mentioned is for the weight of kappa, what I am looking for is the boundary of kappa.
Then I look into https://github.com/ApolloAuto/apollo/blob/master/modules/planning/reference_line/spiral_problem_interface.cc
and I manually change the value of kappa_lower and kappa_upper for the optimizer.
However, these changes do not make any difference in the reference line.
// https://github.com/ApolloAuto/apollo/issues/6710
// Current Lane of the Ego vehicle
Could you please let me know how we can fetch the current lane on which Ego vehicle is currently present. I am using the below code snippet, however it is returning more than 2 lanes. How can I get single lane information.
const int status = HDMapUtil::BaseMap().GetLanes(point, 0.005, &lanes);
static double speed_limit = 0;
int lane_counter = 0;
for (auto& lane: lanes){
const hdmap::Lane& single_lane = lane->lane();
speed_limit = single_lane.speed_limit();
lane_counter = lane_counter + 1;
// ADEBUG << "Speed Limit : " << speed_limit;
}
If you want to get the lane(s) by point, the map may return your multiple lanes since some lanes are overlapped (especially around junctions and turns). This is as expected.
The lane by point is only unique if you talk about the lanes along the routing. There are some methods inside ReferenceLine class to get it.
https://github.com/ApolloAuto/apollo/blob/master/modules/planning/reference_line/reference_line.h
// https://github.com/ApolloAuto/apollo/issues/8283
// How to get obstacle velocity from reference line
Current Apollo API provides a way to get speed of obstacle "obstacle->speed()", my understanding is such speed is always positive which means obstacle always move in the same direction as ego vehicle.
However, In two-way traffic, obstacles may have opposite direction toward ego vehicle.
Is there any API to get the velocity of Obstacle ? positive means same direction and negative means opposite direction with ego vehicle ?
The speed is the absolute value of the velocity. There is also a velocity_heading parameter which shows the velocity direction from 0 to 2*PI.
// https://github.com/ApolloAuto/apollo/issues/7154
// modules/planning/common/reference_line_info.h
const SLBoundary& AdcSlBoundary() const; // means the planning start point
const SLBoundary& VehicleSlBoundary() const; // mean the real time location
//
The main cyber command should be cyber_recorder.
$ cyber_recorder
usage: cyber_recorder > []
The cyber_recorder commands are:
info Show information of an exist record.
play Play an exist record.
record Record some topic.
split Split an exist record.
recover Recover an exist record.
$ cyber_recorder record -h
usage: cyber_recorder record [options]
-o, --output output record file
-a, --all all channels
-c, --channel channel name
-h, --help show help message
$ cyber_recorder split -h
usage: cyber_recorder split [options]
-f, --file input record file
-o, --output output record file
-a, --all all channels
-c, --channel channel name
-b, --begin <2018-07-01 00:00:00> begin at assigned time
-e, --end <2018-07-01 01:00:00> end at assigned time
There is a script for recording data on self-driving vehicles, which could be a reference if that is relevant in your context.
// https://github.com/ApolloAuto/apollo/issues/6914
// Why Apollo stitches reference line? Just for saving computation resource?
For now, we do not support offline reference line smoothing because of the complexity of city lane network. In current implementation, stitching is for stabilizing reference line and saving computation effort
// https://github.com/ApolloAuto/apollo/issues/6809
// Can traffic regulation loading make it possible to add new traffic rules without modifying the code?
I am not sure what you exactly mean. If you want to add a new traffic rule and make it run, you have to create a class/implementation of that rule (please refer to any traffic rule class at https://github.com/ApolloAuto/apollo/tree/master/modules/planning/traffic_rules, as examples), and also create configuration if needed (please refer to https://github.com/ApolloAuto/apollo/blob/master/modules/planning/proto/traffic_rule_config.proto)
And then register your traffic rule as above, to make it effective and run.
void TrafficDecider::RegisterRules() {}
// https://github.com/ApolloAuto/apollo/issues/6615
// smooth the recorded trajectory points
I have a question regarding to the reference line smoothing tool under the directory of /apollo/modules/tools/navigator/smooth.sh.
// Any demo or tutorial to test entire apollo 3.5 stack? #7019
I can think of two ways to test one or more modules.
With dreamview and other modules running in your local dev env.
Make sure you have the input data for the module you are interested in, e.g. they can be played from a record file. You will need to turn on the module you are interested in, and possibly all the downstream modules including sim_control, if you would like to see how your changes affect the way those downstream modules run, and sim_control helps to close the loop by feeding back virtual localization and chassis info. If you are able to observe the output of your module directly on dreamview, then you could just turn on your module.
With Apollo Simulation Platform on the cloud.
Submit your code changes onto a public repository forked from Apollo, and login to the simulation platform https://azure.apollo.auto, which provides about 200 scenarios to test prediction and planning modules currently.
// Why Apollo stitches reference line? Just for saving computation resource? #6914
For now, we do not support offline reference line smoothing because of the complexity of city lane network. In current implementation, stitching is for stabilizing reference line and saving computation effort
// Can traffic regulation loading make it possible to add new traffic rules without modifying the code?
If you want to add a new traffic rule and make it run, you have to create a class/implementation of that rule (please refer to any traffic rule class at https://github.com/ApolloAuto/apollo/tree/master/modules/planning/traffic_rules, as examples), and also create configuration if needed (please refer to https://github.com/ApolloAuto/apollo/blob/master/modules/planning/proto/traffic_rule_config.proto)
And then register your traffic rule as above, to make it effective and run.
planning/traffic_rules/traffic_decider.cc
// decision.proto - MainChangeLane
Change lane is supported through the combination effect from reference line provider, frame, reference line info, and a class called "ChangeLaneDecider".
Please first verify that the routing has a lane change region, otherwise the lane change will not take effect.
// navigation模式下的仿真怎么更新车身位置？ #6067
standard 模式中的 reference line 是 HDMap 中来的, HDMap 是事先采好的，作为本地文件存在硬盘上。
navigation 模式中的 reference line 用了 relative map. relative map 可以是感知实时生成的，仿真时由 rosbag 包中发送的。所以需要播放bag包
standard模式的仿真不需要实时位置，standard模式仿真依赖HDmap，而hdmap是百度已经做好的，所以你只需要选择起始点和终止点，并打开planning模块，车就可以跑起来
navigation模式就是2.5版本中为了方便开发者实车调试添加的，依赖于相对地图，而相对地图又是车实际跑的过程中产生的，如果你要仿真navigation模式就只能播放rosbag包来去提供实时的位置信息，
https://github.com/ApolloAuto/apollo/blob/master/modules/dreamview/backend/sim_control/sim_control.cc
navigation模式:SimControl::OnReceiveNavigationInfo, localization 就是 relative map 实时算出的path的第一个点.
standard 模式:SimControl::PerfectControlModel,localization 就是取的 planning 的trajectory上相对时间对应应的点.
// would it be possible that the use any map to utilize the 'CartesianFrenetConverter' function? #6022
You can use road center line to build reference line. When you have reference line, you can map any point to frenet 's' and 'd'
// 关于相对地图+lattice 多车道超车问题 #5897
Navigation mode supports multiple lanes and lane change in Apollo 3.0. You could use following command to send out multiple navigation lines:
dev_docker:/apollo/modules/tools/navigator$python navigator.py navigation_line_1 navigation_line_2
in this example, navigation_line_1 navigation_line_2 could be navigation line on two adjacent lanes. And navigation_line_1 has higher priority than 2.
// Do not find code to set velocity and accelerate for speedpoint retrieved in DPSTGraph #3535
Why there are no code to set velocity and accelerate for speedpoint retrieved in DPSTGraph
The speed value is not set after st graph, because we only need the value of s and t in the following steps
// dp_st_graph, what is the difference of max_acceleration from vehicle_param and dp_st_speed_config? #3682
The first one is the physical limit of a vehicle, while the second one is what we used in dp st graph as an acceleration limit. The two may or may not be identical, where the second one is usually smaller, as used in our config files.
//
planning/tasks/deciders/path_decider/path_decider.cc
bool PathDecider::MakeObjectDecision(const PathData &path_data,
PathDecision *const path_decision) {
DCHECK_NOTNULL(path_decision);
if (!MakeStaticObstacleDecision(path_data, path_decision)) {
AERROR << "Failed to make decisions for static obstacles";
return false;
}
return true;
}
for (const auto *path_obstacle : path_decision->path_obstacles().Items()) {
const auto &obstacle = *path_obstacle->obstacle();
bool is_bycycle_or_pedestrain =
(obstacle.Perception().type() ==
perception::PerceptionObstacle::BICYCLE ||
obstacle.Perception().type() ==
perception::PerceptionObstacle::PEDESTRIAN);
Currently, we make decisions(Nudge/Stop) for static obstacles in PathDecide.
The decisions(Yield/Overtake and etc) for moving obstacles are made by STGraph.
I read the code, and found that moving obstacles decision is made in speedDecider solver. Just as you said it's made by STGraph. However, why don't make decision for static and moving obstacles in PathDecider solver at the same time? In PathDecider, we have already got moving obstacle prediction trajectory from Prediction Module ros msg broadcast, even in SL graph (not ST graph), we could make decision(Yield/Overtake and etc) for moving obstacle.
we plan path first, and then speed based on path.
Currently we don't have SL graph. We have SL info, but that's not enough to make decision for moving obstacles without dimension of T(time).
once the path has been planed, we make decision for moving obstacles based on STGraph, and a "OVERTAKE/YIELD/STOP" decision (which would be achieved via speed) would be made if their paths may cross ego vehicle path.
In your second graph, ADC may slowdown(follow) or yield to that moving obstacle depending on its path/speed/heading.
// Planning: lane change with SLT graph and obstacle filter
SL graph is based on a single lane frenet frame rather than two lanes.
Moving obstacles only in ST graph.
actually always project moving obstacles into the reference line.
// is EM plannner using the qp Spline Path Optimizer?
in the function of EMPlanner::RegisterTasks(), the qp Spline Path Optimizer is not be registered, is that the qp Spline Path Optimizer is unnecessary？
since QpSplineStSpeedOptimizer is used, why are PolyStSpeedOptimizer used again?
Thank you for reply.
We found that DpPolyPath has result is good enough on road. In addition, the QP-OASES solver may not always return a valid solution, therefore, we skipped the QpSplinePath step. Road driving tests have proved that DpPolyPath is really good.
PolyStSpeedOptimizer is used to make speed decisions for obstacles, and QpSplineStSpeedOptimizer can further optimize the driving speed based on the obstacle decisions
I can not understand how the two tasks work completely. How do the speed decisions made by PolyStSpeedOptimizer exert influence on the QpSplineStSpeedOptimizer? or the two part is independent?
The dp_st_speed will use dynamic programming to find the min cost speed profile, which is used to determine whether we will overtake or yield a vehicle (represented as a st-region on the st graph). Then, those decisions will be treated as hard limits (inequality constraints) in qp_st_speed.
You can ignore poly_st_speed for now, it is still under development. qp_st_speed is the second speed optimizer after using dp_st_speed. You can find the task sequence in modules/planning/conf/planning_config.pb.txt
// Planning failed with one static obstacle ahead the vehicle under SimControl mode #5915
The EM can find a path (dp_poly_path) that why you see the thin "green" line, but the trajectory (thicker green line) for that path will have a collision with the obstacle, that why EM planner fails even when it found a path, in this case, path from dp_poly_path is not a good path.
In order to make EM search for a good path, you have to tune the parameters of EM (change the sample resolution, increase sample in S/L direction...), but it may increase the processing time.
by changing the parameter Step_length_min and step_length_max to 11, can the vehicle successfully pass the obstacle. according to my experiments 11 is the limit value in this case. Thank you all.
// 利用相对地图和lattice planner进行规划 #5864
code 版本： apollo v3.0
相关模块： relative map、planning module
问题：
1、之前看到过V3.0版本支持在相对地图下的lattice planning，请问应该怎么修改代码，https://github.com/ApolloAuto/apollo/blob/r3.0.0/modules/planning/proto/planning_config.proto 中只将planner_type改为NAVI，https://github.com/ApolloAuto/apollo/blob/r3.0.0/modules/planning/conf/planning_config_navi.pb.txt中的planner_type改为Lattice就可以了么？
2、代码中并没有看到navi planner调用em planner或者lattice planner中的代码，怎么看到lattice planner使用的是相对地图呢？
谢谢
我的理解
相对地图+lattice在planning的调用关系是：
/home/alan/apollo/modules/planning/navi_planning.cc
调用planner里面的规划算法，这里面的规划算法有Lattice、Em、NAVI
planner规划算法的位置：
/home/alan/apollo/modules/planning/planner
所以你只要在前面的文档里面设置了LATTICE，同时最好用dreamview里面navigation 模式下的界面进行操作，因为这个界面调用的脚本里面有设置--use_navigation_mode这个模式的参数，设置完
就会运行相对地图+Lattice模式，可以在navi_planning.cc和/home/alan/apollo/modules/planning/planner/lattice/lattice_planner.cc加log查看。
// Trajectory stitching, why? #5033
Can you please explain what is the purpose of stitching trajectories in planning?
Is stitching between lastly published trajectory and something else?
You dont want the car change trajectory every time planner run -> car will change direction frequently
So you keep a portion of previous plan trajectory and stitch it to new trajectory.
Trajectory is much longer than the length of the ego car.
// How to calculate stbounday() ? #5751
I have been going through the Apollo code and having difficulty in understanding how the stboundary() is calculated. I got the point that stboundary it is the "s" values with respect time. However I got the below doubts when going through the st_boundary.cc program.
t value - does this start when the routing starts ?
s values - Could you please let me know from which point the values are being calculated / measured ? Is it taken with respect to Reference line starting ?
If stboundary is empty (IsEmpty() is true), does that mean the obstacle is not moving ?
What does the below functions return in stboundary class
double min_s() const;
double min_t() const;
double max_s() const;
double max_t() const;
Do we see Stgraph on PNC monitor ?
Is QpSplineStSpeedOptimizer is same as ST graph ?
Also similar condition is being checked in backside_vehicle.cc. Could you please explain the below piece of code.
// Ignore the car comes from back of ADC
if (path_obstacle->reference_line_st_boundary().min_s() < -adc_length_s) {
path_decision->AddLongitudinalDecision("backside_vehicle/st-min-s < adc",
path_obstacle->Id(), ignore);
path_decision->AddLateralDecision("backside_vehicle/st-min-s < adc",
path_obstacle->Id(), ignore);
continue;
(1) t value is for time. we plan 0-6s
(2) s: start with the current position of the ego vehicle
(3) it means the obstacle has path would not cross with ego vehicle.
(4) these returns the st boundary of an obstacle. min_t() and min_s() are the (x,y) of the left lower point, max_t() and max_s() are the (x,y) of the right upper point.
(5) yes. StZGraph is on PNC monitor.
(6) this check means that, the obstacle has started behind the back of ego vehicle, and we can ignore it because it is behind ego vehicle.
// Build Stboundary , what is the difference between PathObstacle with StBoundaryMapper? #4785
Hey I m not quite understand what is the difference between BuildTrajectoryStBoundary in path_obstacle.cc and CreateStBoundary in st_boundary_mapper? In both, they set stboundary to a given path_obstacle. So what is the differenece?
They are similar. Build Stboundary in path obstacle uses reference line to pre-build approximate st boundaries.
// How planning module decide emergency stop or not? #4964
I have a check in modules/planning/planning.cc
And I see it will publish planning topic with PublishPlanningPb(&estop, start_timestamp); in some emergency cases.
But I do not know how planning make decision for estop reason or not.Can anyone tell me how to reproduce that case?
The following is estop reseason code:
ESTOP_REASON_INTERNAL_ERR:1,ESTOP_REASON_COLLISION:2,ESTOP_REASON_ST_FIND_PATH:3,ESTOP_REASON_ST_MAKE_DECISION:4,ESTOP_REASON_SENSOR_ERROR:5
In reference_line_info.cc, according to error code, we set estop decision
// check stop decision
int error_code = MakeMainStopDecision(decision_result);
if (error_code < 0) {
MakeEStopDecision(decision_result);
}
MakeMainMissionCompleteDecision(decision_result);
SetObjectDecisions(decision_result->mutable_object_decision());
}
// How two passages are connected? #5253
I think the passage is a single reference line that a vehicle can travel without changing lane.
It looks like routing is a sequence of such passages.
The question is that how two different passages are connected to represent the routing curve?
I think they must be overlapped then correct?
After a destination is given, routing module produces a sequence of end to end zigzag linear segments. Obviously, such lines can't be used for path planning. So a smoothing algorithm on the routing segment is done online to get a differentiable curve, which is called reference line, for the Planning module to work on.
Don't quite understand what is your definition of passages. If you mean the smoothed reference line, then yes. As the current implementation on computing reference line is online, to save computation effort. only a definite horizon of reference line is computed each cycle, so there would be overlapped part. To deal with that, we use stitching to combine two together. Check reference_line_provider.h for more detail.
// PnC monitor elements #5418
The red line: routing line
The slimmest blue line: reference line
The medium width blue belt: dp path line
The widest belt: planning final trajectory
// What's the average computation time to solve a qp_spline_referenceline_smoother #5528
Hi,
To smooth a reference line, normally how many knots you have and what is the average computation time with qpOASES?
Thanks a lot
The number of knots depends on the max length of each spline.
The average computation time depends on your hardware (number of cores, cpu speed, memory, etc.)
Thanks for the reply.
For instance, a 100m curve with 100 splines, running on your AVs, it takes dozens of milliseconds or seconds?
I have tried cvxopt in python as well as qpOASES in c++. Cvxopt takes 50 ms while qpOASES takes 5s to solve the same question.
For a qp problem used in our qp_st_speed_optimizer, the average running time is ~10ms
I ran a simple test in python, not in real-time, 100 cubic splines with 800 variables took 50ms including the matrix assigning.
cvxopt converts automatically a QP to a SOCP, which might be faster in this case
Yes, it could be faster. CXVOPT has an c interface api (https://cvxopt.org/userguide/c-api.html). If you are interested in improving the optimization performance, please feel free to add a cvxopt-based solver into Apollo.
On a Renesas H3 board running qnx, the time to process each configured task in a loop is roughly as the following (apollo r2.0.0):
TrafficDecider: 1 ms
PathDecider: negligble
SpeedDecider: negligble
DpPolyPathOptimizer: 4~6 ms
QpSplineStSpeedOptimizer (use qpOases underlying): 4~6 ms
// Minimal output to be published by the planning module for the control to work #4947
Control will need a list of (x, y t) points to follow.
// EM dp_road_graph #4943
Hi,
This is what I understand about EM.
EM planner generates bundle trajectory and then calculate the cost of each trajectory, and then select the best trajectory by calculating the trajectory cost. After that EM generate the speed profile for that trajectory.
My question is: in trajectory_cost.cc I saw you use some SpeedData to calculate the cost with Dynamic Obstacle.
Base on my understanding, at this step, EM does not generate speed profile yet, so where SpeedData come from?
Thank you.
From the last cycle, remember this is a iteratively planning
// Cost functions for Lattice Planner #4847
In your lattice planner module, you are using 6 cost functions to contribute the whole planner cost:
// Costs:
// 1. Cost of missing the objective, e.g., cruise, stop, etc.
// 2. Cost of logitudinal jerk
// 3. Cost of logitudinal collision
// 4. Cost of lateral offsets
// 5. Cost of lateral comfort
// 6. Cost of centripetal acceleration
Total cost = weighted sum of the costs above, weight of each cost function is defined manually:
// Lattice Evaluate Parameters
DEFINE_double(weight_lon_objective, 10.0, "Weight of longitudinal travel cost");
DEFINE_double(weight_lon_jerk, 1.0, "Weight of longitudinal jerk cost");
DEFINE_double(weight_lon_collision, 5.0,
"Weight of logitudinal collision cost");
DEFINE_double(weight_lat_offset, 2.0, "Weight of lateral offset cost");
DEFINE_double(weight_lat_comfort, 10.0, "Weight of lateral comfort cost");
DEFINE_double(weight_centripetal_acceleration, 1.5,
"Weight of centripetal acceleration");
My question is that in real world, there are many scenarios. How do you pick up the best weight array?
run apollo sdk in apollo Simulation. traverse all the scenarios as many as possible?
Empiricalism based on large-scale road testing?
Currently these parameters are determined empirically, based on our daily urban and highway testing. In future, we expect to develop a more advanced approach that can dynamically determine the weights according to scenarios.
// 关于planning模块的几点疑问，想请教一下 #4763
（1）em和lattice方法实时规划出的轨迹起点是从车体原点出发的吗？如果是，请忽略问题（2）。
（2）一旦轨迹跟踪产生较大误差，如车辆偏出车道外，在其开回期望轨迹的过程中，其碰撞校验是怎么计算的？
（3）apollo是如何防止实时轨迹规划过程中产生的横向抖动？如在高速行驶时，轨迹的横向抖动可能会造成车辆失稳。
感谢提问，我来解答一下：
规划起点有两种可能， a. 车体原点 (在规划的第一周期或者当前车体偏移规划轨迹过大), b. 上一轮周期规划轨迹上本轮相对应的轨迹点。
我们假设车体原点与规划起点的差异并不大（b情况），所以碰转检测只对规划轨迹进行，而没有对实际位置进行。如果差异太大的话， 我们就以车体原点进行规划（a情况）。
横向抖动通过我们对轨迹质量的建模加以数值化，横向抖动的轨迹会赋予一个高的代价，所以一般情况下不会选取。
请看问题之后的回复：
１．em和lattice两种规划器都是您上面解答的情形吗？
是的， 规划起点的决定发生在进入具体的planner之前。
２．针对上面第一个答复：为什么要采用两种规划起点的方式呢？而不是仅仅采用a方式．
主要原因是我们期望得到连续平滑的控制输出。如果每次规划都是从当前位置作为起点的话，控制模块在计算控制误差的时候会发生不连续的现象，进而导致不连续的控制输出。
３．针对上面第一个答复＂b. 上一轮周期规划轨迹上本轮相对应的轨迹点＂：(1)如何在本轮规划时，锁定上一轮周期规划轨迹上本轮对应的轨迹点的位置？（是通过ＧＰＳ坐标锁定该点的绝对位置？）
是通过时间来决定的，由上一个周期的对应点根据周期时间向后推一个周期。
４．假设轨迹跟踪没有横向偏差，但纵向由于加速或制动等原因，使得本周期车辆实际位置偏离上周期期望达到的位置（纵向跟踪偏差）较大，这种情况也会进入起点为" a. 车体原点"的规划吗？
是的
５．假设某一静止障碍物在t~t＋N时刻N个周期内的决策都是避让(nudge)，而在t＋Ｎ＋1时刻，由于前期轨迹跟踪误差等原因，导致该时刻规划的轨迹无法通过该障碍物，从而对该障碍物的决策变为不可避让（刹停）；apollo是如何防止在规划过程中，避免这一类决策结果在前后周期的不一致性？［注：如果人工驾驶的话，对某一静止的障碍物的决策一般是固定的，要么避让，要么刹停．］
首先,对于横向误差，我们设置的临界点比较小，大概是几十厘米，所以您提到的这个问题出现的情况比较小。
其次，决策在周期间不一致的问题普遍存在（我们可能不应该称之为“问题”，“现象”更为合适）。决策需要根据当前车辆状态实时作出调整，可以想象成一个更高级的feedback control。
３．针对上面第一个答复＂b. 上一轮周期规划轨迹上本轮相对应的轨迹点＂：(1)如何在本轮规划时，锁定上一轮周期规划轨迹上本轮对应的轨迹点的位置？（是通过ＧＰＳ坐标锁定该点的绝对位置？）
是通过时间来决定的，由上一个周期的对应点根据周期时间向后推一个周期。
“上一周期的对应点向后推一个周期”得到的轨迹点是如何映射到本周期的坐标系下呢？[假设上一时刻t0的轨迹前两点依次是p1(t0)、p2(t0)，如何求得p2(t0)在当前时刻t1的(车体坐标系下的)坐标p2(t1)呢？]
// What's the difference between rtk planner, em planner, and lattice planner? #4674
RTK Planner started at Apollo 1.0, which is used to plan the pre-set trajectory for the follow-through algorithm.
EM planner started in Apollo 1.5 and has been abandoned in 3.5. Based on dynamic planning and quadratic planning, it first carries out path planning and then speed planning, which is suitable for complex scenarios.
The EM planner has been tested to work at 0 - 105 kmh (0 - 65 mph).
Lattice planner started with Apllo 2.5, and it also carries out path planning and speed planning, which is suitable for simple scenarios.
// Vehicle frame orientation #4584
It is FLU. I think what you want is in the https://github.com/ApolloAuto/apollo/blob/master/modules/planning/planner/navi/navi_planner.h
// SL coordinate intial point? #4414
The origin of SL coordinate is the center point at a starting point of a lane.
Frenet coordinates and SL coordinates are the same thing. SL coordinates can be converted to XY coordinates. Apollo has SL is used for path planning, ST is used for velocity planning, and ST is used for collision detection.
// In file /apollo/modules/planning/conf/planning_config.pb.txt, it includes two speed optimizers:
...
task : DP_ST_SPEED_OPTIMIZER
task : SPEED_DECIDER
task : QP_SPLINE_ST_SPEED_OPTIMIZER
...
If we remove QP_SPLINE_ST_SPEED_OPTIMZER, the car does not move.
It is also noticed that QP_SPLINE_PATH_OPTIMIZER is not registered with any planner.
The DP_ST_SPEED_OPTIMIZER is for decision purposes. QP_SPLINE_ST_SPEED_OPTIMIZER will generate the quantitative trajectory.
Currently, we do not use QP_SPLINE_PATH_OPTIMIZER. Only poly_path is used.
// How to use/modify/implement new algorithm in planning module? #3462
// https://github.com/ApolloAuto/apollo/issues/3462
--- to change to another planner, please (1) add your planner name in planning_config.proto (line 31 - 35); (2) define the config of your own planner in planning_config.proto (after line 29); (3) change "planner_type : EM" to the one you have in planning_config.pb.txt.
--- Because the car in the rosbag has position info pre-recorded, it cannot follow your planning trajectory. If you want to make the car follow a generated path, you need to turn on the "SimControl" button (tasks->others) in the dreamview. Under the sim-control mode, the dreamview will receive the planning trajectory and help to move the car for you to mimic the driving process.
--- Since the planning results were recorded in the rosbag, you will observe the trajectory by just playing the bag. You can filter the /apollo/planning topic from the rosbag in order to test your own planning.
Thank you for being patient with me. I really appreciate your support.
This is what I done so far:
#filter the planning module
rosbag filter ./docs/demo_guide/demo_2.0.bag ./docs/demo_guide/demonew.bag "topic== '/apollo/planning'"
#run the new bag
rosbag play -l ./docs/demo_guide/demonew.bag
But in the Dreamview, nothing shows, the Default Routing button is grey out, could not select.
I think the filter should be "topic != '/apollo/planning'" (not == ). The topic will be kept if it the expression is true.
To start planning module, please (1) build the project you have modified (using bash apollo.sh build) (2) run the planning binary in a separate terminal (using bash scripts/planning.sh), or just turn on the planning from dreamview.
// DP boundary conditions ? #1614
I have a question about EM planner.
What I understood is that some boundary conditions are found by solving some optimization problem using Dynamic Programming. What exactly those boundary conditions? Are they speed limits and lane boundaries?
Thank you!
The concept of boundary conditions is used for quadratic programming (QP).
The boundaries come from the road (such as road speed limits, lane boundaries), vehicle dynamics (e.g. curvature, acceleration of a trajectory), and other obstacles.
One more thing. There is another kind of boundary --- regions in S(path)-T(time) graph that represent the mapping of obstacles in a S-T coordinate system (maybe this is the one you mentioned ?).
In a DP process, the distance between a point (s, t) and the obstacle S-T boundaries are calculated and a cost is assigned based on the distance.
DpStSpeedOptimizer: the dotted line is the optimization results from dynamic programming.
QpSplineStSpeedOptimizer: the dotted lines are some reference lines calculated in task/qp_spline_st_speed/qp_spline_st_graph.cc (line 337 and line 391).
QpSplineStGraph::AddCruiseReferenceLineKernel
QpSplineStGraph::AddFollowReferenceLineKernel
QpSplineStGraph::AddYieldReferenceLineKernel
Thank you and sorry for keep bugging you.
Yes, the line of DpStSpeedOptimizer must be the optimization result of DP. Can you please provide its physical meaning? Thank you!
The result is a list of (s,t) points, meaning at some time t, we would like the vehicle to travel a distance s (starting from the current position) on the generated path.
// how to create hdmap?
Good information, but let us say I have no HDmap. How do I create one? I see there are some tools, like create_map_from_mobileye.sh and create_map_from_xy.sh (which can presumably be used with UTM coordinates), but are there any tools in Apollo that will allow you to add junctions and signals and link roads together? How did the Apollo team create the sunnyvale_loop demo maps, and is that technology available to Apollo users in any form?
There is no method or tools to generate base_map.xml directly from GPS and LiDAR data now. The steps we generate Apollo HDMap are roughly as follows:
collect Lidar data,GPS data, IMU data, Camera data, etc. through HDMap collection vehicles;
process point cloud data using technologies such as Lidar SLAM;
Identify road elements through machine learning, deep learning,etc. to generate HDMap data, which may contains some misidentified data.
manually correct the automatically generated HDMap and construct logical relationships between the map elements to generate the final HDMap.
The technology we create the HDMaps is not available to users now, but we will open our methods how to collect map data through HDMap collection vehicles in the near future.
// Uses of PerceptionSLBoundary() and reference_line_st_boundary() #5183
Hi All,
I have been going through the Apollo code and getting confused in the below point.
PerceptionSLBoundary() -- This gives the trajectory for the Obstacle using the protobuf. (It gives 4 values start_s, end_s, start_l and end_l).
What does this reference_line_st_boundary() gives ? - Looks like it returns the class object from the class. Whether this creates a 2D box around the obstacle ?
Why there are 2 boundaries for single perceived obstacle ?
Could you please clarify my doubt?
Thank you,
KK
// Traffice decider tasks #4838
Hi All,
Can anybody please give me some insights on how the traffic decider tasks are formulated.
If you could provide me a document with the explanation of each tasks would be great.
Directory: apollo/modules/planning/tasks/traffic_decider/
Thank you,
KK
The traffic decider tasks are to make rule-based decisions on ego vehicle and obstacles. It is highly scenario related so that you can find multiple deciders in the folder. I suggest reading codes in that folder for details. It is complex, but not complicated.
@kk2491 we do not have document or readme at this point. it is pretty much self-explanatory if you read the code, the classes at traffic_decider folder.
e.g.
for traffic light, the ego vehicle would stop behind the stop line of the specific traffic light if red light is detected.
for crosswalk, the ego vehicle would stop behind the stop line of the specific crosswalk if there is pedestrian(s) or bicycle(s) are passing through that crosswalk.
etc.
Hope the information answered your question.
Thank you for supporting Apollo!
@jmtao .. Thanks for the response. I have tried the tasks. In case of Cyclist, the autonomous car does not follow the obstacle even if the speed of the cyclist is higher than the threshold. It does stop and go.
Could you please let me know if there is any other conditions?
@kk2491 can you be more specific or post screen shot of your DreamViewer? ADC follows the bicycle if the bicycle running along ADC current reference line. If the bicycle stops ADC would stop.
// Build Stboundary , what is the difference between PathObstacle with StBoundaryMapper? #4785
@lianglia-apollo Hey I m not quite understand what is the difference between BuildTrajectoryStBoundary in path_obstacle.cc and CreateStBoundary in st_boundary_mapper? In both, they set stboundary to a given path_obstacle. So what is the differenece?
They are similar. Build Stboundary in path obstacle uses reference line to pre-build approximate st boundaries.
// What does longi_coef and longitudinal_coef mean? #4274
// https://github.com/ApolloAuto/apollo/issues/4274
Polynomial function for x/f and y/g is based on "world frame". When consider boundary constraint in reference line smoother, we should map polynomial function coordinates (x,y) into FLU frame to calculate difference of lateral distance and longitudinal distance between predict position and ground truth position.
"longi_coef" is the projection coefficient vector in L axis, while 'longitudinal_coef ' is the projection coefficient vector in F axis.
assume:
x=f(t)=a0+a1t+a2t2+a3t3+a4t4+a5t5
y=g(t)=b0+b1t+b2t2+b3t3+b4t4+b5t5
define:
A=[a0,a1,a2,a3,a4,a5]T
B=[b0,b1,b2,b3,b4,b5]T
C=[1,t,t2,t3,t4,t5]
(A,B)=(AT,BT)T
such that:
x = f(t) = CA
y = g(t) = CB
According to anchor point heading, we know:
unit direction in F axis: (cos(heading), sin(heading)), also equal to (-sin(heading-pi/2), cos(heading-pi/2))
unit direction in L axis: (cos(heading+pi/2), sin(heading+pi/2)), also equal to (-sin(heading), cos(heading))
Then map predict point from "world frame" to FLU frame, we can get lateral and longitudinal distance:
lateral distance: (-sin(heading), cos(heading)) · (CA, CB) = (-Csin(heading), Ccos(heading))(A, B)
longitudinal distance: (-sin(heading-pi/2), cos(heading-pi/2)) · (CA, CB) = (-Csin(heading-pi/2), Ccos(heading-pi/2))(A, B)
Note:
A · B means two vector inner product
AB means matrix multiplay(dot)
· above means inner product. Here (-Csin(heading), Ccos(heading)) is the "longi_coef", which is the projection coefficient vector in L axis. (-Csin(heading-pi/2), Ccos(heading-pi/2)) is the 'longitudinal_coef ' , the projection coefficient vector in F axis.
d_lateral and d_longitudinal is the lateral and longitudinal distance of ground truth point(anchor point), so we can boundary constraint:
constraint in L axis: |d_lateral - longi_coef(A,B)| <= lateral_bound
constraint in F axis: |d_longitudinal - longitudinal_coef(A,B) | <= longitudinal_bound