{"id":332,"date":"2020-04-02T21:45:51","date_gmt":"2020-04-02T21:45:51","guid":{"rendered":"http:\/\/mrsdprojects.ri.cmu.edu\/2020teamd\/?p=332"},"modified":"2020-11-13T22:16:14","modified_gmt":"2020-11-13T22:16:14","slug":"risk-management","status":"publish","type":"post","link":"https:\/\/mrsdprojects.ri.cmu.edu\/2020teamd\/2020\/04\/02\/risk-management\/","title":{"rendered":"Risk Management"},"content":{"rendered":"
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n\u00a0<\/th>\n<\/tr>\n<\/thead>\n
\n
1<\/span><\/div>\n<\/th>\n
Sl No<\/strong><\/span><\/td>\nRisk Name<\/strong><\/span><\/td>\nRisk Description<\/strong><\/span><\/td>\nRisk Consequences<\/strong><\/span><\/td>\nRisk Type<\/strong><\/span><\/td>\nLikelihood<\/strong><\/span><\/td>\nConsequence<\/strong><\/span><\/td>\nReduction Plan<\/strong><\/span><\/td>\n<\/tr>\n
\n
2<\/span><\/div>\n<\/th>\n
R1<\/span><\/td>\nRL Agent does not converge for mandatory scenarios<\/span><\/td>\nThe RL agent does not converge to show reasonable performance<\/span><\/td>\nFailure to achieve mandatory project functional requirements<\/span><\/td>\nTechnical<\/span><\/td>\n4<\/span><\/td>\n5<\/span><\/td>\n1) 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.<\/span>
2) Try out imitation learning.<\/span>
3) Seek out assistance from colleagues who have previously worked in this domain.<\/span><\/td>\n<\/tr>\n
\n
3<\/span><\/div>\n<\/th>\n
R2<\/span><\/td>\nCan’t build hardware due to College Shutdown (No more a risk)<\/span><\/span><\/span><\/td>\nLoss of access to the lab due to a shutdown can lead to delays and suspension of hardware related tasks.<\/span><\/td>\nHardware POC delivarable needs to be pushed to next semester<\/span><\/td>\nSchedule<\/span><\/td>\n5<\/span><\/td>\n5<\/span><\/td>\nFinish most of the software work this semester, so we can focus on Hardware POC next semester.<\/span><\/td>\n<\/tr>\n
\n
4<\/span><\/div>\n<\/th>\n
R3<\/span><\/td>\n\n

Difficulty to integrate <\/span>(No more a risk<\/span>)<\/span><\/p>\n<\/td>\n

Since all teammates are working remotely, there is communication feedback loop is slower and might lead to difficulty in integration of work packages.<\/span><\/td>\n1) Large delays in delivarables<\/span>
2) Major redesign of the system<\/span><\/td>\n		Technical<\/span><\/td>\n3<\/span><\/td>\n4<\/span><\/td>\n1)Manadatory meetings atleast twice a week.<\/span>
2)Daily standups with teammates.<\/span><\/td>\n<\/tr>\n
\n
5<\/span><\/div>\n<\/th>\n
R4<\/span><\/td>\nLack of Variation in Simulted Scenarios<\/span><\/td>\nThe ability of the simulator to generate different scenarios might be limited<\/span><\/td>\nCan lead to overfitting in the RL Algorithm, which can lead to system wide delays.<\/span><\/td>\nTechnical<\/span><\/td>\n2<\/span><\/td>\n4<\/span><\/td>\n1) Look at alternate simulators<\/span>
2) Create custom scripts to increase scenario variability<\/span>
3) Create custom scenarios<\/span><\/td>\n<\/tr>\n
\n
6<\/span><\/div>\n<\/th>\n
R5<\/span><\/td>\nLack of Computation Power (No more a risk<\/span>)<\/span><\/td>\nDuring subsystem integration, having all the involved subsystems running simutaneously may need more computation power than a single computer<\/span><\/td>\n1) Lower Frequency Interface Frequency than expected<\/span>
2) Lower Trajectory Frequency than expected<\/span>
3) Vehicle Failing to Respond in Real Time<\/span><\/td>\n		Technical<\/span><\/td>\n2<\/span><\/td>\n5<\/span><\/td>\n1) Design thread and core allocation in advance<\/span>
2) Keep computationally intensive subsystems modular to be able to run in different computers<\/span><\/td>\n<\/tr>\n
\n
7<\/span><\/div>\n<\/th>\n
R6<\/span><\/td>\nFixed trajectories made by rule based path planner does not produce effective results<\/span><\/td>\nThere is a chance that fixed trajectories might not work best for dynamic scenarios.<\/span><\/td>\nBuilt system might not be the most robust one.<\/span><\/td>\nTechnical<\/span><\/td>\n2<\/span><\/td>\n2<\/span><\/td>\n1) Design a path planner which is atleast robust to some parameters like speed limits, obstacles in path, etc.<\/span>
2) Customising the trajectories based on scnearios and not using the same one.<\/span><\/td>\n<\/tr>\n
\n
8<\/span><\/div>\n<\/th>\n
R7<\/span><\/td>\nHardware\/Simulation data distribution mismatch (No more a risk)<\/span><\/span><\/span><\/td>\nThe RL agent trained on simulation might not work on the sensor rig directly, because the data does not come from the same distribution.<\/span><\/td>\nFailure of hardware demo<\/span><\/td>\nTechnical<\/span><\/td>\n4<\/span><\/td>\n4<\/span><\/td>\n1) Assign time to testing<\/span>
2) Assign time to convert sensor data into similar representations as in simulation.<\/span>
2) Collect real world data and retrain RL agent.<\/span><\/td>\n<\/tr>\n
\n
9<\/span><\/div>\n<\/th>\n
R9<\/span><\/td>\nLack of results on CARLA<\/span><\/td>\nThe dynamics of vehicle motion in CARLA might be too complex for our decision making algorithm to process.<\/span><\/td>\nFailure to achieve mandatory project functional requirements<\/span><\/td>\nTechnical<\/span><\/td>\n3<\/span><\/td>\n4<\/span><\/td>\n1) Simpify vehicle dynamics by modifying CARLA souce code.<\/span>
2) Add vehicle dynamics like bicycle model to the simple simulator.<\/span><\/td>\n<\/tr>\n
\n
10<\/span><\/div>\n<\/th>\n
R10<\/span><\/td>\nFrenet Coordinate System is ineffective<\/span><\/td>\nA 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.<\/span><\/td>\nFailure to complete building a full system as a lot of components are going to be modified to accommodate Frenet coordinate system.<\/span><\/td>\nTechnical<\/span><\/td>\n3<\/span><\/td>\n4<\/span><\/td>\n1) 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.<\/span><\/td>\n<\/tr>\n
\n
11<\/span><\/div>\n<\/th>\n
R11<\/span><\/td>\nState extraction in CARLA is too complex<\/span><\/td>\nCARLA’s APIs may not be directly amenable to extract the details we want in a easy manner. Especially in intersection scenarios.<\/span><\/td>\nWill be major blocker for getting intersection negotiation working.<\/span><\/td>\nTechnical<\/span><\/td>\n3<\/span><\/td>\n2<\/span><\/td>\n\n

1) Get the help of sponsors who are experienced with using CARLA.<\/span><\/p>\n

2) Try simulating intersection scenarios in the simpler simulator we had developed using rviz in the last semester.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n