safety-critical-control-wirin/sccav_cbf

Safety Critical Control of Autonomous Vehicles by Control Barrier Functions

SCCAV - CBF

Safety Critical Control of Autonomous Vehicles by Control Barrier Functions

sccav_cbf's Issues

Abnormal / Sporadic behavior in the CARLA simulation (single_obstacle_CBF.py), and reference controller related bugs

Bug Description
This is to report the various bugs that were encountered while running the CARLA simulation through the single_obstacle_CBF.py file. The recurrent and reproducible bugs observed so far which might be a consequence of the code's mistakes are:

1. Ever since the Stanley controller's gain k was changed, the car tends to decelerate and come to a halt after moving a few meters when the reference velocity is set to 5 m/s. However, incrementing the velocity to 6 m/s seems to resolve this issue. This hasn't been tried for v < 5 m/s. Note that the behavior started after the CBF class DBM_CBF_2DS() was integrated and the CodeOptions enumerations were added to switch between different modes of simulation; however, removing the CBF doesn't make a difference. Running the code after removing the CodeOptions enumerations hasn't been tried yet.
2. When the CBF activates and starts circumventing around the obstacle, the steer input tends to oscillate. The oscillation amplitude appears to be directly proportional to the ego vehicle's velocity. Therefore, for a sufficiently high velocity (around > 13 m/s), the circumventing maneuver fails drastically as the car takes unstable lateral oscillations and takes a huge detour around the obstacle eventually colliding into its surroundings.
3. LateralStanley() fails to track properly at higher velocities. This is possible due to the stable steering set varying at different speeds, thus requiring different gains for different speeds as well as different reference velocities such that the lateral stability is maintained while taking turning maneuvers.

Bugs which might be not be related to a logical mistake in the Code, and might be an external program's fault:

1. [Possibly related to 1. in previous list] The velocity keeps on monotonically increasing sometimes, as if the throttle is jammed in the very beginning when the PID makes the car accelerate from rest to reach the non-zero reference velocity. This bug occurs sporadically and restarting CARLA server seems to fix it for some time.

Bugs which are possibly happening due to incomplete model information:

1. The vehicle is somehow tracking the trajectory through the right wheels when it should conceptually be the COM tracking the trajectory. The exact reason can't be pinpointed, but the following crucial parameters involved are not known about in detail and require further investigation:
   - The distance of front axle from the COM (l_f) is not known.
   - The location of the COM w.r.t the Bounding Box center is known; but the location of wheels (from carla.VehiclePhysicsControl()) don't appear to be w.r.t the same reference. Furthermore, their actual reference point is not determined.

To Reproduce
As of commit d4e4969, the following steps should reproduce the behavior:

1. Open the CARLA server using ./CarlaUE4.sh -opengl -quality-level=Low -RenderOffScreen.
2. Execute the single_obstacle_CBF.py script with the following options in the CodeOptions enum class: INSTANTLY_START_EGO_ENGINE = True, and set CBF_MODE to CodeOptions.ACCELERATION_CBF.
3. The requisite condition for the each bug beyond this point is mentioned in the bug description above.

Expected behavior

1. The car shouldn't come to a halt at any non-zero velocity and should track the trajectory without coming to a halt as long as the reference velocity is non-zero.
2. The trajectory shouldn't be tracked by the rightmost portion of the car, but through the COM instead.
3. Since CARLA is being run in synchronous mode, the behavior for all runs should be reproduced without any variations between runs. Therefore, the sporadic monotonic increase in velocity shouldn't occur.
4. As long as the boundary of the unsafe region is smooth and free of oscillations, the steer command modifications issued by the CBFs shouldn't oscillate and follow the unsafe region's (the obstacle) boundary profile.

Screenshots
No screenshots available, please follow the steps above to reproduce the error. Checkout the above mentioned commit if HEAD has moved on.

Desktop:

• OS: Ubuntu 20.04 Focal Fossa
• GPU: nVIDIA RTX 2080 Ti (12 GB)
• RAM: 16 GB

cbf.utils.Timer class doesn't allow inheritence

Bug Description
Setting the timestamp attribute as a property (using the @property decorator) doesn't allow classes to derive from the cbf.utils.Timer() class.

To Reproduce
Try inheriting from the cbf.utils.Timer() class.

Expected behavior
Successful inheritance allowing for the usage of the timestamp attribute for ROS related time-stamping and synchronization for objects of the cbf.obstcles module relying on timely state updates.

Desktop:

• Ubuntu 20.04 Focal Fossa
• Python 3.8.7