2020 Work Log

I didn’t pass the exam in the end. Ugh, it’s been rough.

I went for the exam in the morning and got a few things done in the afternoon:

1. Went to Yiming’s to look into an anomaly, which turned out to be two bugs.
2. After the town hall in the afternoon, synced up on the MDK Python binding stuff.
3. Together with Shan Le and Wei Yu, went downstairs to resolve an issue with an upstream project and ultimately came up with both a short-term fix and a long-term solution.

I’ve noticed that when unexpected problems arise, the typical approach to solving them follows this pattern:
a short-term fix and a long-term solution. The value exposed by the problem is limited and time-sensitive, so the short-term fix aims to quickly and accurately address the immediate urgency. But is a long-term solution still needed? Generally speaking, yes — because the specific instance of a problem often reveals a blind spot in the original solution that wasn’t considered before. Analyzing the root cause and systematically solving it ensures that this type of problem can be handled well in the future, making the original solution more complete. There are cases where a long-term solution isn’t necessary — when after a thorough analysis we conclude that the cost of systematically fixing the problem outweighs the benefit. (Even then, most of us subjectively want to address it systematically — as engineers, who wouldn’t? But this also poses a trap: it can lead us to spend time on important-but-not-urgent or even neither-important-nor-urgent matters, wasting valuable time that could be used to solve other more valuable problems.)

4. Came back in the evening to continue working on the CI pipeline.

Tomorrow is the driving test subject 2. I practiced driving all day today and only came back at 5 PM. I feel pretty good, hope I can pass tomorrow.

Started describing the current status and requirements analysis of the CI Pipeline - -

If nothing unexpected happens today, I will finish the CI Pipeline tasks.

But something unexpected happened - -

Received bug reports from Yiming:

1. Traffic light binding: The traffic light that should be bound to the waiting area was bound to the partition before the waiting area. Fixed (1.5h)
2. Traffic light binding missing: Could not reproduce. Update: After a round of difficult debugging, finally found the issue: during compilation, the geometry used for binding rc and offset was not on the same road segment, causing the offset to exceed the road length, so the traffic light could not be found (2h)

Today, many unexpected events happened. First, two bugs were reported in the parking module. Originally scheduled for delivery today, it could not be delivered on time due to these bugs. Wang Wei negotiated with downstream and postponed the delivery by two days to the day after tomorrow. So my main task for these two days has turned back to fixing bugs. It made me wonder whether the delivery schedule was reasonable. Then there was the issue with HDMAPMDK-1290.

Things accomplished today:

• Follow-up on HDMAPMDK-1290: When extremely close to the stop line, the matched lane offset can be longer than the lane length.

  Spent the whole day investigating and trying to solve this problem (currently 8:56 PM). The efficiency was very low.

  The root cause is that MDK calculates the length by taking a coordinate transform at each pair of points. Although this is more accurate, it introduces strong uncertainty in the result.

  Finally used a hack: whenever the calculated offset is longer than the length, just take the length.

• HDMAPMDK-1297: Parking spot binding error. Although it’s almost the original end-of-work time (9 PM), I must at least analyze this problem today! Phew, got it done. It turned out to be a simple issue.

Today I received a new task: HDMAPMDK-1249 - Investigate using road geometry information to calculate lane aggregation methods. This added a few more tasks to this week. As of now, I still have three things to do:

1. 1249
2. Current status, requirements, and solutions for the team’s CI Pipeline
3. Nexus graph refactoring

Each of these requires careful consideration and is not easy, but unfortunately, I cannot clearly estimate the time for each one. They are all estimated by Weiyu and written into the story points of the JIRA tasks. One thing I’m clear about: If I don’t start estimating and reviewing, I will never estimate accurately. So starting this time, I will estimate carefully.

Also, I plan to start working on 1249 today. Since it’s a business matter, it’s generally more urgent, and Weiyu will also care more about this. As for the refactoring, if I don’t pay attention to it myself, probably no one else will care (because it’s harsh: it doesn’t affect functionality, but it affects efficiency, and efficiency is the hardest to measure; even I only have qualitative analysis).

What did I do on this day???? What did I do????

TODOs

• Greet Qiaobo
• HDMAPMDK-1262
• HDMAPMDK-755

Works

• Went to the Yiming work area in the morning to debug yesterday’s hotfix online. The issue turned out to be caused by an offset error. I wrote the fix too hastily yesterday and didn’t add any tests at all. This kind of behavior should not happen again. I thought I was saving a lot of time, but in the end, I wasted even more time.
• The reason why 1262 couldn’t fetch data is that the MDK did not load the lane-level road marks (and road obstacles).
• Helped Brother Du compile the data.

• Write documentation describing the current nexus/mdk CI status and requirements.
• Follow up on HDMAPMDK-1263 bug
  • It is indeed a production line splitting issue.
• Arrange a meeting with Yang Chuan to discuss CI
• HDMAPMDK-1262 Not finished
• The Custom Speed Limit issue

Fixed a bug in OSM Assembler (actually not a bug)

Had a sprint planning meeting today: There isn’t much to do this sprint, but there’s a lot to think about. It’s a healthy state.

Refactored the OSM Assembler using the previous OSM serialization. The code has become easier to understand and more convenient to write.