The following is written from an acting-engineers perspective. The solutions and ideas proposed for now don't have direct impact on the Planning department. However such a structural change should be communicated and discussed early.
As mentioned in #358 the interface between Planning and Acting should be improved upon.
(In #371 there is a more detailed documentation about the current interface)
Currently the acting receives inputs from multiple different sources:
Trajectory Path in world coordinates. This gets sent from the planning department.
The current position and heading: As sent by the perception node (GPS location)
The current speed directly off the carla interface
The target velocity as sent from planning
The "current_behaviour" - such as unstuck
The emergency topic, which can be broadcasted by everyone
There are several improvements for the interface i have in mind:
The Acting department should not need any information about global positions etc. In my opinion all information should be shared in relative car coordinates.
We would therefore not need the gps information (2)
The path received from motion planning could already have the target velocity information encoded in the path. From an actors perspective there are two "velocities" we have to keep an eye on.
First: A speedlimit or other external limiting factors
Second: The dynamics of the vehicle limit the maximum speed
The trajectory should only have speed limits as the factor, not internal dynamics
The emergency topic should not be used as extensively as it is currently used now.
I therefore propose the following solution for the interface:
The Acting receives a trajectory with included velocities (speed limits etc). This trajectory should be in a local coordinate system.
In this trajectory the current unstuck routine (5. current_behaviour) as well as the planned emergency stops should be included.
This would be inspired by e.g. the Formula1 Games "Ideallinienanzeige" (If i am not wrong they show accelerations in the visuals - i think velocities are more appropriate for us)
This would reduce the inputs to the following:
Trajectory in local coordinates, includes velocities
Current speed from carla interface
An emergency topic which i personally would like to scrap, but might be usefull for now.
Transitioning to such a completely new interface will certainly not be easy. I therefor suggest the following:
In the first step we implement a pre_acting package, which does the transformation from current inputs to the suggested interface.
This will be plenty of work, because e.g. reverse driving is not yet implemented yet and some of the steering logic for this will need to be thought about. During this time the rest of the system doesn't have to change.
In the second step the pre_acting package gets integrated into the motion planing package. My understanding about the motion planning package is limited, I assume however this will be quite a bit of work.
Still executing step 1 would be beneficial for the acting package as also the architecture could be improved upon during transitioning. Especially because currently steering and throttle are computed completely separately from one another.
The architecture changes should probably receive there own issue.
Description
The following is written from an acting-engineers perspective. The solutions and ideas proposed for now don't have direct impact on the Planning department. However such a structural change should be communicated and discussed early.
As mentioned in #358 the interface between Planning and Acting should be improved upon. (In #371 there is a more detailed documentation about the current interface)
Currently the acting receives inputs from multiple different sources:
There are several improvements for the interface i have in mind:
I therefore propose the following solution for the interface: The Acting receives a trajectory with included velocities (speed limits etc). This trajectory should be in a local coordinate system. In this trajectory the current unstuck routine (5. current_behaviour) as well as the planned emergency stops should be included. This would be inspired by e.g. the Formula1 Games "Ideallinienanzeige" (If i am not wrong they show accelerations in the visuals - i think velocities are more appropriate for us) This would reduce the inputs to the following:
Transitioning to such a completely new interface will certainly not be easy. I therefor suggest the following: In the first step we implement a pre_acting package, which does the transformation from current inputs to the suggested interface. This will be plenty of work, because e.g. reverse driving is not yet implemented yet and some of the steering logic for this will need to be thought about. During this time the rest of the system doesn't have to change. In the second step the pre_acting package gets integrated into the motion planing package. My understanding about the motion planning package is limited, I assume however this will be quite a bit of work.
Still executing step 1 would be beneficial for the acting package as also the architecture could be improved upon during transitioning. Especially because currently steering and throttle are computed completely separately from one another. The architecture changes should probably receive there own issue.
Definition of Done
No response