Risk Management
|
1
|
Sl No | Risk Name | Risk Description | Risk Consequences | Risk Type | Likelihood | Consequence | Reduction Plan |
|---|---|---|---|---|---|---|---|---|
|
2
|
R1 | RL Agent does not converge for mandatory scenarios | The RL agent does not converge to show reasonable performance | Failure to achieve mandatory project functional requirements | Technical | 4 | 5 | 1) Build the first RL agent as soon as possible and finish every other task as soon as possible, so we have time and man-power to prototype different algorithms. 2) Try out imitation learning. 3) Seek out assistance from colleagues who have previously worked in this domain. |
|
3
|
R2 | Can’t build hardware due to College Shutdown (No more a risk) | Loss of access to the lab due to a shutdown can lead to delays and suspension of hardware related tasks. | Hardware POC delivarable needs to be pushed to next semester | Schedule | 5 | 5 | Finish most of the software work this semester, so we can focus on Hardware POC next semester. |
|
4
|
R3 |
Difficulty to integrate (No more a risk) |
Since all teammates are working remotely, there is communication feedback loop is slower and might lead to difficulty in integration of work packages. | 1) Large delays in delivarables 2) Major redesign of the system |
Technical | 3 | 4 | 1)Manadatory meetings atleast twice a week. 2)Daily standups with teammates. |
|
5
|
R4 | Lack of Variation in Simulted Scenarios | The ability of the simulator to generate different scenarios might be limited | Can lead to overfitting in the RL Algorithm, which can lead to system wide delays. | Technical | 2 | 4 | 1) Look at alternate simulators 2) Create custom scripts to increase scenario variability 3) Create custom scenarios |
|
6
|
R5 | Lack of Computation Power (No more a risk) | During subsystem integration, having all the involved subsystems running simutaneously may need more computation power than a single computer | 1) Lower Frequency Interface Frequency than expected 2) Lower Trajectory Frequency than expected 3) Vehicle Failing to Respond in Real Time |
Technical | 2 | 5 | 1) Design thread and core allocation in advance 2) Keep computationally intensive subsystems modular to be able to run in different computers |
|
7
|
R6 | Fixed trajectories made by rule based path planner does not produce effective results | There is a chance that fixed trajectories might not work best for dynamic scenarios. | Built system might not be the most robust one. | Technical | 2 | 2 | 1) Design a path planner which is atleast robust to some parameters like speed limits, obstacles in path, etc. 2) Customising the trajectories based on scnearios and not using the same one. |
|
8
|
R7 | Hardware/Simulation data distribution mismatch (No more a risk) | The RL agent trained on simulation might not work on the sensor rig directly, because the data does not come from the same distribution. | Failure of hardware demo | Technical | 4 | 4 | 1) Assign time to testing 2) Assign time to convert sensor data into similar representations as in simulation. 2) Collect real world data and retrain RL agent. |
|
9
|
R9 | Lack of results on CARLA | The dynamics of vehicle motion in CARLA might be too complex for our decision making algorithm to process. | Failure to achieve mandatory project functional requirements | Technical | 3 | 4 | 1) Simpify vehicle dynamics by modifying CARLA souce code. 2) Add vehicle dynamics like bicycle model to the simple simulator. |
|
10
|
R10 | Frenet Coordinate System is ineffective | A major amount of development time will be spent on setting up a system which can work on curved roads. There is a chance that it might not be more effective than euclidean system. | Failure to complete building a full system as a lot of components are going to be modified to accommodate Frenet coordinate system. | Technical | 3 | 4 | 1) In case frenet is ineffective, just feed in euclidean coordinates in the respective fields of the ROS message to ensure other systems which depend on these interfaces do not get affected. |
|
11
|
R11 | State extraction in CARLA is too complex | CARLA’s APIs may not be directly amenable to extract the details we want in a easy manner. Especially in intersection scenarios. | Will be major blocker for getting intersection negotiation working. | Technical | 3 | 2 |
1) Get the help of sponsors who are experienced with using CARLA. 2) Try simulating intersection scenarios in the simpler simulator we had developed using rviz in the last semester. |