At the beginning of the course, you have seen this picture. Now you might guess the reason why behavior modules are updated less frequently than e.g. trajectory modules.
This is due to decisions made by high-level behavior modules that take longer timeframes and just don't change as often.
But the trajectory module still relies on our decision and the importance of the overall system architecture does not allow slower modules
The behavior planner records the normal operation of other faster components. Let's take a second to talk about the so-called scheduling problem and how to deal with it in a self-driving car.
This diagram shows what happens during the two processing cycles of the behavior module.
As you can see, the prediction module is updated more frequently than "behavior". The trajectory is higher. etc.
But notice what happens after the behavior completes the first cycle.
To start the second round, the behavior module needs data from prediction and localization.
For localization, it's theoretically easy, and at the moment it has some new data and behavior to use it.
But what about forecasting. At this instant, it's actually in the middle of an update cycle.
Should the behavior wait until the prediction is complete? No, if we start waiting then we block the pipeline of the downstream component.
The answer is to use data from here and accept that it's a bit stale.
When you implement half the planner of the final project, we will give you the code to handle all of these issues.
But it's worth mentioning how this is done.