AWS DeepRacer — The NAB Story
Part one
About the authors: Paul Kukiel is a Senior Cloud Architect at NAB, helping to build out capabilities in the areas of serverless and compliance. Prior to this Paul worked in Cloud tech roles in the financial services, realestate and betting industries.
Chris Rhodes is a NAB intern studying computer science at Deakin University. With a love for programming from a young age, Chris dreams of creating technology that everyone can use.
Paul:
I’ll set the scene by describing what DeepRacer is and what I can extrapolate as the larger intent behind AWS launching such a service. It all started at AWS re:Invent 2018 where Dr Matt Wood, GM of Deep Learning and AI at AWS introduced DeepRacer — you can watch the video here.
You are reading this article because one you are interested in tech, two you have an interest in machine learning and AI or three, you simply think DeepRacer is cool and it’s not a jump to consider that your interest spans across all three. Our industry currently is all about big data and machine learning and AI, but in practice we struggle with the opportunities and outlook, it’s the new buzz word and while we often have an idea how to implement the mechanics, we don’t have the application to get started. Hence Amazon releasing DeepRacer the “get started with Machine Learning” tool and make it fun.
Now let’s fast forward a few months, re:Invent excitement has settled down, NAB team members are back from Christmas leave. The NAB cloud guild inspired by Shruti Saddi and NAB’s CIO Yuri Misnik threw out the idea that “We should be doing something with this DeepRacer”, hence our very own DeepRacer Community of Practice (COP) was formed to see what could be achieved.
At NAB, teams are encouraged to experiment with new concepts and technologies; when DeepRacer Console was in preview, we started off using SageMaker and RoboMaker to train and evaluate models, which is much more intensive and customisable then the console itself. We had many people keen on joining the COP, including Chris Rhodes, an intern at NAB. From here things get technical so we cover the journey in two separate articles. Part one delves into getting started, the early technical issues and the fun factor with part two focusing on hyperparameters, custom libraries, cloud9 and docker builds.
The DeepRacer console was not yet in GA so the path Chris described was a huge benefit for us, it was not overly tricky but pretty quickly we wanted to do more. This was really a benefit as members of the COP began digging deep to see how far we could go with this challenge.
It was after the first few DeepRacer COP meetings that we decided to build a track. These tracks are not small, in fact they require over 100 connected floor tiles (7.9 x 5.1 meters). We were ready to get our hands dirty and start building, however, we received welcome executive support and we were able to purchase a track. It was an exciting meetup when it arrived, and we were eager to watch the DeepRacer drive around the track. When I say drive around the track, I really mean drive around in circles! We had very little luck on the first outing, but it was fun and more and more members became involved.
Chris:
Many people heard about this COP through different means, for me, Christopher Rhodes, co-author of this article and third place winner for AWS Summit Sydney DeepRacer, I heard about it as an off-note for one the presentations during my induction week at NAB.
There are many ways to train the models for DeepRacer — which we’ll get into in part two.At our first COP meeting we were forming teams. The room was split into four based on how much AWS and Machine Learning experience we each had. I put myself in the Machine Learning corner. Once in our teams had a basic presentation of DeepRacer in the Jupyter, notebooks followed.
A lot of people had a number of issues getting Sagemaker working inside the notebooks due to a couple of reasons. Some bugs in the provided setup itself and other issues from a lot of us having no idea what was going on in the notebook. I suffered from both. As time went on, there was little activity in the teams and not many people were making progress. People weren’t fully engaging and for me, there were a couple of reasons for this. One being the notebook was terrible to iterate with. It took a solid five minutes to start a training job, and a couple more minutes for it to fail, then a couple more for it to stop; just horrible for quick iterations. I was pretty apathetic with it all and it wasn’t until the COP scheduled a large workshop for everyone that things begun to change for me.
The large workshop was for everyone, including those outside of the COP. It was great fun. We had a couple of people from AWS come and do a presentation about DeepRacer and it gathered a lot of interest within NAB. The presenters gave us an overview of DeepRacer and really helped bring everyone up to speed, albeit lacking in too much detail. It was here that the question of running it on our own PCs (I refer to it as running locally) was brought up, and I chimed in saying the documentation said it wasn’t possible. It was after this that I said I wanted to prove them wrong.
After deciding to get DeepRacer running locally, I faced a lot of technical and motivational challenges. There was no specific technical challenge that was difficult, but the sheer breadth of knowledge that was required made everything that little bit harder. I had to patch most components inside the AWS-provided samples and components to allow it all to run locally.
Once I was deep in trying to get it running, I recognised more reasons for doing it. Running it locally would enable longer training, full back up of every training checkpoint, full debugging of every component, full access to the simulation, easier and faster modification of the simulation, as well as no AWS costs and the enjoyment of the technical challenge.
Paul:
As we approached the Sydney Summit, NAB had several keen members with trained models that looked ready to race. To help ease the nerves we setup our track in the foyer of the NAB 700 Bourke Street Building in Melbourne. I was proud of our efforts and really wanted to show the whole company (If you work at 700, you’d have walked past the foyer every morning) what we have been working on in our lunchtimes and dedicated research time, as well as the fact that machine learning is accessible to all, even those with entry level skills.
We had a ton of interaction and prizes and we brought along some pre-trained models and let people race them, with a chance to win some prizes donated by AWS. The event was a huge success and at this point we believed we had a chance of making the leader board for the Summit. It was also around this time that the DeepRacer console was made GA. Which we will go into in part two.
For more information, follow this link: https://aws.amazon.com/DeepRacer/
Chris:
When I arrived at the Summit, I didn’t go to the DeepRacer track until half way through day one and my first couple of models were duds on the track — they were unable to stay on the track and didn’t complete laps very quickly (I took four, and built one there). It wasn’t until I tried the model I built for NAB’s internal competition that I saw a good time. My second attempt with the winning model had a time of 00:09.230. I’m not sure where the time sits in world records, but I do know it’s in the top 10. I’ll be pretty honest; it’s all a bit of blur. My anxiety was pretty bad at this point, and paired with some sleep deprivation from the event itself, my memory is impaired. I remember being awarded the trophy and speaking on the podium. Having my photo taken and actually meeting and talking to the other podium finishers. That was lots of fun.
The biggest take away for me has been being able to work on a technical challenge, and then use that work to achieve something that other people care about. It’s surreal that as an intern people are contacting me asking for help or advice on DeepRacer.
If you’re interested in learning more and about working in technology at NAB, click here.
