Development blog for TORCS project.
by Lewis
Continuing from a productive week 4 where our PPO model achieved a 1:41.66 on the Corkscrew, this week with a separate module assessment around the corner we focused on a less taxing but equally important part of the project: risk assessment.
While not as exciting as developing and testing our model it is still a crucial foundation of making sure we are able to complete our task with as little hiccups as possible.
Risks and action:
As we proceed with development the stakes and risks increase. We’re training models, managing shared codebases, working towards a client set deadline, and trying to cooridinate this all between a team of six. As the weeks go on and we delve deeper into the project the risks stack up evermore so it is imperative that we stay on top to reduce the possibility of problems accumulating and stalling the project.
Non-technical or project risks are risks that don’t involve code but human and organisational errors.
This originates from poor communication and cooridination of team members. If members stop attending meetings, stop communicating, stop contributing, or fall out of sync with each other then the project’s progress crumbles. As a preventative we have our Team Operating Agreement, our Whatsapp group, and designated meetings every week which are all effective in promoting communication and coordination within our team.
Technical or systems risks are risk directly involving the code.
Training corruption, interruption, and model loss are what we identified as the highest impact risks. As well as reward hacking and catastrophic forgetting, which is where the agent games the reward function without actually progressing towards the goal and where earlier behaviours is unlearnt due to a poor reward signal. Both mitigated with frequent benchmarking and specific reward function design.
TORCS behaves inconsistently across different devices which is a problem for a team of six working on varying machines. We will be testing on multiple devices to make sure no unexpected errors or deviations occur.
Once we had identified the risks we then documented them in a way that’s useful and easy to read, providing value for the team and our client.
We created a structured risk register that included all the risks we could think of and assigning each a probability score and a severity score which we combined to give us an overall impact score relating to our project. We added a colour coded low-high impact key for each risk so we can clearly identify which ones to keep an eye out for while also including mitigation tips for each risk. Both additions add value for both ourselves and the client.
tags: