Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abrupt and aggressive speed control #431

Open
seitzseb opened this issue Nov 4, 2024 · 1 comment
Open

Abrupt and aggressive speed control #431

seitzseb opened this issue Nov 4, 2024 · 1 comment

Comments

@seitzseb
Copy link
Collaborator

seitzseb commented Nov 4, 2024

Detailed Description

The agent’s speed controller is overly aggressive when accelerating from green lights, leading to abrupt starts and stops. This behavior results in uncomfortable and potentially unsafe maneuvers in traffic situations.

Definition of Done

Speed control is smoother when accelerating from a stop, with no abrupt starts and stops.
Agent accelerates and decelerates in a controlled manner in various traffic conditions.

Effort Estimate

5

Testability

Test in a variety of stop-and-go scenarios, particularly at traffic lights, to confirm smooth acceleration and deceleration without sudden jerks.

Dependencies

Depends on proper sensor data feedback and any control code revisions related to speed adjustments.

@vinzenzm
Copy link
Collaborator

vinzenzm commented Nov 4, 2024

As the changing traffic light gets recognized correctly I will remove perception label.

The issue arises because there is infinite acceleration possible with the current throttle controller.
Therefore this is primarily an acting issue. There should be less acceleration when starting from a standstill.

We could decide on also planning an acceleration pattern for specific situations. E.g. accelerate faster if Firestruck approaches from side. Accelerate slower because next traffic light is red anyway. Therefore I will add the planning label inttermittently.
Currently however the interface between acting and planning would not allow for this. This issue is therefore also related to #421 where I supposed a new Interface between acting and planning.

I therefore suppose 3 different solutions with increasing implementation effort:

  1. Limit acceleration in acting routine by limiting throttle command on low speeds.
  2. Implement proper trajectory planning (S-Curve profile)
    https://www.pmdcorp.com/resources/type/articles/get/mathematics-of-motion-control-profiles-article
  3. Solution 2 with the addition of above mentioned interface to be able to adapt to future speed limits or more.

@seitzseb as far as I am aware of this there is no penalty in the driving score for such jerky movement.
I will therefore add label p_3 as low priority.

If we decide on not involving planning (not Solution 3) we can also remove planning label.

My personal opinion would be so see if any issues with driving performance arise from this eratic behaviour before spending to much time on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants