About accelerate or decelerate in `ModelExample.py`
maple-zhou opened this issue · comments
It seems that the code doesn't address accelerate or decelerate?
I have read the source code, and all the functions concerning trajectories do not take accelerate or decelerate into control.
Is this temporary and will be updated in the future?
Or am I wrong? Is there something I haven't noticed?
Thank you for using LimSim. I understand that you want to control the behavior of the vehicle by inputting acceleration and deceleration. However, LimSim controls the movement of the vehicle through trajectories. The definition of trajectories can be found in ./utils/trajectory.py, in the Trajectory and State classes. Our Trajectory is composed of a series of States, each of which includes information about the vehicle’s position, speed, yaw, and acceleration. In ModelExample.py, we use the function model.setTrajectories() to plan future trajectories for the vehicle. The input to this function is a dictionary where the keys are the vehicle ids and the values are the planned trajectories.
Thanks for your response, I've got what you meant.
Then there is another question:
In ./trafficManager/common/vehicle.py, the class Behaviour contains some elements, including
KL = 0
AC = 1
DC = 2
LCL = 3
LCR = 4
STOP = 5
IN_JUNCTION = 6
OVERTAKE = 7
OTHER = 100
I only found behaviours 'KL', 'LCL', 'LCR', 'STOP', 'IN_JUNCTION' are processed, it seems that the codes do not process 'AC', 'DC' (I guess they refer to 'accelerate' and 'decelerate' respectively), so is it now meaningless in the code?
For example, in ./trafficManager/planner/trajectory_generator.py, the function decision_trajectory_generator only parse 'LCL' and 'LCR' of decision.action, then other actions (I guess action corresponds to behavoiur one-on-one) are meaningless when generating trajectories.
Thank you for your in-depth use of the LimSim code. In the trafficManager module of LimSim, we plan the trajectory for vehicles through the prediction-decision-planning steps. The behavior generated by the decision process is passed to the planning module to generate the trajectory. As you mentioned, our AC and DC behaviors are not explicitly handled, this is because the planning module automatically determines the vehicle’s speed and acceleration. Therefore, AC, DC, and KL are the same for our planning module, but the vehicle can still make acceleration and deceleration actions.
Of course, users can write their planning modules to replace our planning module, so that each behavior can take effect. We reserve these behaviors so that users can more easily customize the planning module without having to consider the upstream decision module, making it easier for users to use. 😊
Thanks for your quick response!
So if I want to use my own decision_maker, it seems it's enough to only transfer desicion.action consisting of 'LCL' and 'LCR'?
In fact, if you just want to write a decision_maker for the ego, you can take a look at the EgoPlanner.plan() function in ./trafficManager/planner/ego_vehicle_planner.py. In this function, our planning module can handle 5 behaviors including KL, STOP, LCR, LCL, and IN_JUNCTION.
Similarly, if you want to make multi-vehicle decisions, you can refer to the MultiVehiclePlanner.generate_trajectory() function in ./trafficManager/planner/multi_vehicle_planner.py, which also supports multiple behaviors. 😊
Ohh I've got the logic of the code. Thanks very much of your active response!!!
By the way, In MultiVehiclePlanner.generate_trajectory()(Line 70 of ./trafficManager/planner/multi_vehicle_planner.py), why is it a limit of 10 / 3.6?
After receiving the upstream behavior, our planner module also has a safety check. We don’t just plan a keep lane trajectory based on the KL instruction, but first determine whether the vehicle needs to stop. That is to say, when the vehicle speed is lower than 10/3.6, we will first determine whether the vehicle needs to stop. If it needs to stop, we will generate a STOP trajectory, otherwise, we will continue to generate a KL trajectory.
If you want the planner module to faithfully execute the upstream behavior instructions, you may need to modify the code to remove the safety check part of the planner module.
In addition, thank you for your in-depth understanding of LimSim’s code. If you are interested, you can join our WeChat group chat to discuss together. 😊
Thanks a lot for your detailed explanation! I have joined the WeChat group.
After receiving the upstream behavior, our planner module also has a safety check. We don’t just plan a
keep lanetrajectory based on theKLinstruction, but first determine whether the vehicle needs to stop. That is to say, when the vehicle speed is lower than10/3.6, we will first determine whether the vehicle needs to stop. If it needs to stop, we will generate aSTOPtrajectory, otherwise, we will continue to generate aKLtrajectory.If you want the planner module to faithfully execute the upstream behavior instructions, you may need to modify the code to remove the safety check part of the planner module.
In addition, thank you for your in-depth understanding of LimSim’s code. If you are interested, you can join our WeChat group chat to discuss together. 😊
The QR code is invalid. Can you resend it?
After receiving the upstream behavior, our planner module also has a safety check. We don’t just plan a
keep lanetrajectory based on theKLinstruction, but first determine whether the vehicle needs to stop. That is to say, when the vehicle speed is lower than10/3.6, we will first determine whether the vehicle needs to stop. If it needs to stop, we will generate aSTOPtrajectory, otherwise, we will continue to generate aKLtrajectory.
If you want the planner module to faithfully execute the upstream behavior instructions, you may need to modify the code to remove the safety check part of the planner module.
In addition, thank you for your in-depth understanding of LimSim’s code. If you are interested, you can join our WeChat group chat to discuss together. 😊
The QR code is invalid. Can you resend it?
