This is kind of fundamentally flawed in my mind. If you have some path planner using dubin motion models, what’s the difference between identifying a left/right turn at the sampling time versus on executing the path? Either way, you’re just assigning a L or R value to some information which it itself self contains the L or R information. So doing this in the planner or the controller (either) is a pretty arbitrary decision because both have access to identical information to make an identical decision.
I definitely understand semantically it makes more sense to stick in the planner because its “at” planning time, but logically the controller is the one that needs to make the decision about whether to slow or not depending if left or right. So if there’s some logic in the controller already to take that L or R and slow based on the right one, why not also determine L or R at that time as well? Particularly because a robot never perfectly follows a path so to make a robust system, you’d need to verify in the controller again in case of dynamic effects or obstacle information different in the local costmap settings that could soften or deepen the turn to track the path.
If L or R is part of the planning sequence, that’s different, but it sounds like you’re just classifying the turn and not using the load information as an additional planning heuristic (and even if you were, both are still valid options).
Given the common separation of a path vs local trajectory planner, the local trajectory planner seems like the right place since “slowing” is varying speed, which is more of a “trajectory” than a “path”. I’m not arguing that you couldn’t also do it in the path planner, but unless you’re doing full kinodynamic planning, it seems overkill to change the interfaces for certain areas which can be easily taken care of via other existing tools / methods.