Exploding angular velocity

[abhaybd]

Describe the bug
I've found that by taking certain actions, the simulator can be prompted to calculate impossibly large angular velocity values. Once the angular velocity starts exploding, it creates a runaway effect and can increase to millions or billions of radians/sec.

To Reproduce
The following code example produces an angular velocity of -82084.6562721812, which is obviously impossible.

from f110_gym.envs import F110Env
from f110_gym.envs.base_classes import Integrator
import numpy as np


env = F110Env(num_agents=1, integrator=Integrator.Euler)
env.reset(np.array([[0, 0, -0.5]]))

max_reverse = env.params["v_min"]
max_steer = env.params["s_min"]

for _ in range(5):
    _, _, done, _ = env.step(np.array([[0, max_reverse]]))
    assert not done

for _ in range(25):
    obs, _, done, _ = env.step(np.array([[max_steer, max_reverse]]))
    assert not done

print(obs) # notice that angular velocity is impossibly large

I'm currently training reinforcement learning algorithms with this environment, but runs keep failing because the agent may accidentally trigger this behavior. Is this a bug in the dynamics? This behavior appears for both euler integration as well as RK4, even after the bugfix introduced by #52.

[kenblu24]

I've noticed that the last three states (yaw, yaw rate, slip angle) all go to infinity when this happens. Slip angle seems to be the most aggressively growing one, while the other states piggyback off of that. I haven't looked into the dynamics deeply, but is it possible that the dynamic model itself has this issue?

[meraccos]

I am also having the same issue. Setting the integrator to Euler seems to delay the explosion, but it eventually happens in my RL code.

EDIT: The problem is with the backwards motion + steering combination, the states explode almost always, very quickly. Solution is limiting the action space. You can get a feel for the controller with this keyboard control example

[raphajaner]

Hi All,

As there seems to be some work for a v1 release but I haven't seen a decent solution to this issue yet, I wanted to propose a simple approach to avoid/fix it. AFAIK the problem comes from the dynamic model when driving backward. There's no issue with the kinematic model which is used for low velocities anyway:

    # switch to kinematic model for small velocities
    if abs(x[3]) < 0.5:
        ...

An easy and IMO reasonable fix could be extending the use of the kinematic model to negative velocities by simply removing the abs(). This might be less realistic but as we should be more interested in driving forward, I feel like it's still sufficient:

    # switch to kinematic model for small velocities
    if x[3] < 0.5:
        ...

I ran the test from above and didn't see any issues.

LMKWYT!

[hzheng40]

Fixed by #100, switched to kinematic model when backing up. We've tried to investigate this, but it seems like it's just a singularity with the dynamics when the dynamics model is scaled down to 1/10 size.