2020 作業日誌

バグ修正

• HDMAPMDK-1215 完了
• HDMAPMDK-1218 完了

HDMAPMDK-1132 ポール標識の車線端点におけるIDトレーシング

ポール標識の車線端点におけるトレーシングの問題は、線形オブジェクトのトレーシングと比較して非常に単純であり、IDのマッピングのみで、オフセットや長さのマッピングはありません。

しかし、考慮すべき点も少なくありません。

1. 手順（Procedure）
2. ID型付けシステム（Id Typing System）は根深い問題であり、何らかの対策が必要です。

本質的に、この問題の根源は、IDを定義する際にすべてLong IDを使用しているのに対し、MDMの定義ではIntが使用されているため、オーバーフローの問題が発生する可能性が高いことにあります。

Bugfix: HDMAPMDK-1211 解決方法を思いつく

• 根本原因は、生産ラインの分割が不適切だったことです。

原因分析

車線変更がまだ終了していない時点（車線中心線が車線境界線をまたいでいる時点）で、すでに分割が行われていることがわかります。また、このような分割はRpをまたぐ可能性があります。

車線中心線（lanecenter）の形状点に付随する車線境界線（lane border）の観測情報は、幾何形状に忠実に、スキャンライン方式で両側の車線境界線を記録しており、意味に基づくフィルタリングは行われていません。そのため、車線境界線が車線をまたぐ位置では、車線境界線と交差する車線中心線が、その車線境界線を左右両方の車線境界線参照（lane border ref）に同時に記録することになります。

既存のコードロジックでは、意味に基づいて交差する車線境界線の境界線参照（border ref）をフィルタリングする際に、車線変更のタイプから削除すべき境界線参照（border ref）を推定します。

しかし、現在のロジックはこのような分割に遭遇すると機能しなくなり、その結果、問題が発生します。

解決方法

核心は交差する車線境界線の変更傾向（変道趨勢）を特定することにあります。このような分割はRpをまたぐ可能性があるため、フィルタリングはRp単位で行うべきではありません。

1. まず、車線境界線をエッジリフティング（edge lifting）を用いてパス（将来のグラフ再構築を考慮）にまとめます: Seq[LaneCenter]
2. 修正が必要な車線中心（LaneCenter）と、修正が必要な車線境界線（lane border）を特定します（ここでは、このような車線中心は必ず車線変更によって生じたものと仮定します）。
3. LaneCenterのパスに基づいて、そのLaneCenterの変更傾向を計算します。
4. フィルタリングを実行します。

子良に任せました。

面接で1人不合格となりました。

• 面接：2人の候補者はどちらも不合格。候補者を迅速に見極める方法を検討し、3時間を費やした。
• バグ修正：HDMAPMDK-1211 誤ったborderを削除する問題について、前回の修正で成功しなかった。 方針はあるが、書き終えていない。
• ジムに行った。

• HDMAPMDK-1122 道路边缘線欠損問題は再現されなかったため、原因調査に時間を費やすのをやめることにしました。
• 代謝成長論を30分間
• Visitorのリファクタリングにより、同一始点・終点のラインをサポートするようになりました。
• 面接問題を1つ準備しました。

PolyLineの修正とテスト

PolyLineの問題は主に、PolyLine生成時に重複点が混入する可能性があり、その結果、幾何学的なセグメント計算に一連の問題が発生することです。

1. ベクトル計算：2つの重複点からゼロベクトルが算出される
2. 長さ計算：セグメント長が0となり、NaN問題が発生しやすい

そこで、PolyLine構築時にPolyLine内の点をチェックし、重複点が見つかれば例外をスローするようにしました。

以下の問題が確認されました。

• JtsのgetEndで問題が発生

• Jts LinearLocationに正規化の問題が存在する

  val loc1 = new LinearLocation(0, 1, 1.0)
  val loc2 = new LinearLocation(0, 2, 0.0)
  
  loc1 compareTo loc2
  // 出力は -1
  

• Interpolate時に、互いに近すぎる2点を取得する可能性がある

メモリリーク問題

• メモリリーク問題の直接的な原因は、ダングリングポインタを new した後、delete しなかったことです。
• 現在位置を更新した後、map kit が prepareGuidanceData を呼び出し、現在位置に最も近いガイダンスデータを見つけようとします。
• prepareGuidanceData は NavInfoProviderImpl::getTrafficLights と NavInfoProviderImpl::getCarParks を呼び出します。
• NavInfoProviderImpl::getTrafficLights を例にとると、呼び出し時に NaviEventOnPath 内のデータポインタを new で生成しています。
• しかし、delete が行われていません。
• また、DestEvent にも同様の問題があることが判明しました。

解決策: 根本的にはダングリングポインタを許さないことであり、NaviEventProvider に対してリファクタリングを行うことにしました。

• まず、NaviInfoProvider に traffic_light_events と car_park_events という 2 つのフィールドを追加します。
• NaviInfoGenerator で、ルートが更新された後にこれら 2 つのフィールドを更新します。
• そして、get が呼ばれるたびに、現在の車両位置に基づいてフィルタリングを行います。
• そのため、PathReader::getAttributes をリファクタリングする必要があります。理由は、これまでの実装では現在の車両に対する相対オフセットのみを考慮していたため、パスに対するオフセットインターフェースが必要になるからです。

Du Valid

• mill を使用しました
• nexus-osm を使用しました

ブレインストーミング

バグ修正

• HDMAPMDK-1143
  RoadObstacleがコンパイルされない問題
• HDMAPMDK-1090
  RoadObstacleとLaneChangeActionインターフェースの適合
• HDMAPMDK-858
  全シナリオフレームワークの統一と、全シナリオ設定インターフェースへの型定義の追加
• HDMAPMDK-1073
  Autoware変換新要件の設計レビュー

学科試験を受けましたが、半日かかりました。

HDMAPMDK-1130 の幅に関する問題、3つの問題点：

1. 仕様では、車線変更時には車線幅がないと規定されています。
2. intersection（交差点）の線が長すぎることに起因するスプリットライン。

HDMAPMDK-1121 の再修正を行いました。

状態が非常に悪かったです。