Summary
This paper presents PADriver, an MLLM that takes a rasterized BEV image of traffic scenario as well as a personalized prompt as the inputs, and then outputs the driving actions that follow the driving behavior described in the personalized prompt. The paper also presents a dataset called PAD-Highway, which consist of partly rule-generated and partly human-based driving logs in HighwayEnv scenario.
Strengths
1. The paper is clearly motivated.
This paper has a very clear motivation: enabling personalized autonomous driving with MLLM. This is an interesting direction and can potentially lead to interesting technical contributions or datasets.
2. The paper provides human-labeled logs in the proposed PAD-Highway dataset.
In the PAD-Highway dataset, this work presents 25 hours of human-based driving logs and scores for driving experience in the HighwayEnv environment. I believe this collection of human-labeled data will be useful for future works.
Weaknesses
1. The necessity of making PADriver a MLLM for HighwayEnv is unclear.
The most important contribution of this paper is the proposed PADriver, which is an MLLM trained for HighwayEnv. As mentioned in Line044, the main reason is that only providing text description is not sufficient to capture enough scene information. Therefore, they use vision inputs with BEV rasterizations.
However, in fact, the BEV image from HighwayEnv does not provide any additional information than all the agent's locations in the scenario, which can be easily extracted as float numbers and provided as either text input or vectorized low-dimensional features. Therefore, it is unclear to me why is using vision input necessary and what benefits it provides for HighwayEnv. It seems to me using text inputs or simply agent-location vectors will be sufficient.
In short, I agree that vision input might be important for more realistic environments like CARLA. However, as this work only conducts experiments on HighwayEnv, the purpose of using MLLM is unclear.
2. The necessity to train the MLLM PADriver instead of directly prompting SOTA MLLMs is unclear.
Related to the last part, PADriver is trained with a large amount of driving data generated by rule-based policies as well as human annotations. However, because the BEV rasterization in HighwayEnv is a very easy and intuitive representation of the scenario, it might be very likely that current MLLMs (e.g., GPT4o) might be already able to solve the PAD problem with relatively good performance.
DILU has already proved that pure-text GPTs are already able to do well in HighwayEnv with text input, I believe with proper prompting and input formatting, it is very straightforward to modify DILU's prompts and use GPT4o to take in the image input and output personalized driving behaviors. To show the necessity of training an MLLM to solve this issue, I believe including GPT4o's performance is important.
3. The use of personalized driving prompts is very limited.
Although the paper has an emphasis on "personalized driving prompts", the kind of personalization is only limited to "slow, medium, and fast" and do not include very detailed personalized prompting like "always try to drive on the leftmost side", "try to keep a distance of 10m from the car in front", "do not exceed acceleration of XX level".
The reason why the detailed personalized prompts are expected is that the PADriver is an MLLM, it is very natural for it to take in free-form and high informative language descriptions of the personalized needs. The current support for 3 levels of speeding can be simply input to the model with a one-hot vector with 3 dimensions, without any text involved.
As personalized driving is the core focus of this paper, I think this limitation becomes an important drawback of this work.
Questions
1. Table 3: is Table 3 having a fair comparison? Need to highlight the differences.
In Table 3 several compared methods are included, some of them (e.g., DILU) do not take the same input format, some of them are not trained or finetuned on the same dataset as PADriver. To compose a fair comparison and understand why PADriver is doing well, it is necessary to highlight these important differences.
2. Line315: What's the performance of the rule-based policy in the proposed benchmark?
A large portion of the driving data in the PAD-Highway dataset is generated by the rule-based method, and PADriver is trained on this set of generated data. It becomes very interesting how the rule-based policy perform on the benchmark in the paper; after all PADriving is imitating this rule-based policy.
If this rule-based policy can perform well on the benchmark, the necessity to train PADriver becomes questionable.