Hi, thank you for releasing this project. I have been reading the paper and exploring the codebase, and I have a question regarding the control pipeline described in Section 3.4.
The paper states that for longitudinal control, the speed of the computed driving-style waypoints is checked against predefined velocity ranges. If the speeds are consistent with the selected driving style, the driving-style waypoints are used; otherwise, the system falls back to temporal waypoints.
While reviewing the implementation, I noticed a couple of points that seem slightly different from this description.
1. Velocity range alignment check
The paper mentions checking the speed of the selected driving-style waypoints against ranges such as (0, 0.4), (0.4, 3), and (3, 999). However, I could not find an explicit check for this in the code. The adapt_status flag in SparsePlanDecoder seems somewhat related, but it is disabled by default and appears to select waypoints based on the current ego speed rather than verifying whether predicted speeds fall within the predefined ranges.
2. Fallback to temporal waypoints
The paper indicates that if the waypoint speed is inconsistent with the selected driving style, longitudinal control should fall back to temporal waypoints. In the current implementation, plan_temp_name is set to 'plan_speed_5hz', and control_pid seems to always use the driving-style waypoints for speed control.
In pid_controller.py, the desired_speed is computed directly from the driving-style waypoints without an explicit consistency check. The only related condition I found is desired_speed < self.brake_speed (0.4) in hipad_b2d_agent.py, which appears to act as a braking threshold rather than a velocity-range check.
Could you clarify whether the velocity range alignment check or the fallback to temporal waypoints is implemented elsewhere in the code, or if this behavior differs from the paper in the current implementation?
Any clarification would be greatly appreciated. Thank you again for open-sourcing this project.
Hi, thank you for releasing this project. I have been reading the paper and exploring the codebase, and I have a question regarding the control pipeline described in Section 3.4.
The paper states that for longitudinal control, the speed of the computed driving-style waypoints is checked against predefined velocity ranges. If the speeds are consistent with the selected driving style, the driving-style waypoints are used; otherwise, the system falls back to temporal waypoints.
While reviewing the implementation, I noticed a couple of points that seem slightly different from this description.
1. Velocity range alignment check
The paper mentions checking the speed of the selected driving-style waypoints against ranges such as (0, 0.4), (0.4, 3), and (3, 999). However, I could not find an explicit check for this in the code. The adapt_status flag in SparsePlanDecoder seems somewhat related, but it is disabled by default and appears to select waypoints based on the current ego speed rather than verifying whether predicted speeds fall within the predefined ranges.
2. Fallback to temporal waypoints
The paper indicates that if the waypoint speed is inconsistent with the selected driving style, longitudinal control should fall back to temporal waypoints. In the current implementation, plan_temp_name is set to 'plan_speed_5hz', and control_pid seems to always use the driving-style waypoints for speed control.
In pid_controller.py, the desired_speed is computed directly from the driving-style waypoints without an explicit consistency check. The only related condition I found is desired_speed < self.brake_speed (0.4) in hipad_b2d_agent.py, which appears to act as a braking threshold rather than a velocity-range check.
Could you clarify whether the velocity range alignment check or the fallback to temporal waypoints is implemented elsewhere in the code, or if this behavior differs from the paper in the current implementation?
Any clarification would be greatly appreciated. Thank you again for open-sourcing this project.