Navigation

Wednesday, February 13, 2019

My Misadventures in Coding an Autonomous Racer



I've promised myself that 2019 will be my year of return. 2017 was kinda hard for me and I wanted to treat 2018 as my recovery year, to which I successfully did it in the final days of the year by finishing my paper. I started out this year with a bang by having a thesis seminar in January (from now on, any instance of "final paper" would be considered as "bachelor's thesis" here) and since then I've been busy with completing my administrative requirements for my thesis defense which in turn is the reason why I don't post anything about this Awards Season on my other blog. So far, nothing's special happening as all that remains is the waiting towards this year's Oscars, the awards season for TV ended in SAG Awards, and the online couple competition hasn't begin yet, maybe next week? Nobody knows...

One week ago, however, the same day where I properly posted something nice on Instagram again like above embedded post, was where the end of the road for me in a spectacularly successful fashion despite the college feeling like a ghost town with only a few people around which would explain why there's a lack of more festive shots after my thesis defense. Yes, the actual word I was looking for to describe the final test for my final paper is basically "Bachelor's Thesis Defense" ("Bachelor's Thesis", as in the "final paper" I always refer to + "Thesis Defense") which I did during when the photo was taken by one of my supervisors (obviously). It actually went well despite a little stuttering at some point, and there was the feeling where I opt for straightforward actions, answering the examiners' questions without any difficulty since the topic I've chosen was in sync to my interests and the fact that I struggled during the development of the application helped a lot.

But then you started to wonder what kind of application I developed that it took too long for me to develop it. It is actually something to do with artificial intelligence, something I haven't considered as I tried to find something that could reach my multimedia roots as well. Apparently, I came across a game that eclipses both entertainment and education values needed for my project in the form of The Open Racing Car Simulator (TORCS), an Open Source racing game that has been used by researchers as a platform to test out artificial intelligence-based controllers of varying approaches. Considering that the game has been used by international researchers and I came across zero papers from my country that discussed this topic, the decision was ultimately made at that moment. The project took roughly more than a year due to the fact that I have to re-learn programming languages, as well as the approach I use and how to make a controller in the game, but the end result was satisfying enough.


GIMME MO' TORCS

In case you are looking for Celtic Torcs then this is the wrong place" -Bernhard Wymann, better known as berniw. (Image: TORCS @ Sourceforge.net)

The Open Racing Car Simulator or TORCS is an Open Source game created by Eric Espié and Christophe Guionneau and is currently headed by Bernhard Wymann (berniw), plus with additional contributors. The game features realistic effects such as lighting, smoke, skid marks, and glowing brake lights, plus a simulation of a simple damage model, collisions, tire, and wheel properties such as springs, dampers, and stiffness, as well as car aerodynamics and much more. Here, you can play many types of race modes varying from single races, championship races, and practice, and split screen is available up to four human players. It is also highly portable and runs on all Linux architectures, as well as Windows operating systems.

While it might not sound as promising to you, the unique point of this game is that you could program your own computer-controlled driver(s), which are referred as "controllers". In other words, not only it is a playable game for human players, but it is also an AI racing game. The bot tutorial by berniw gives you the insight of how you could develop your own computer-controlled driver in the race. Keep in mind that each "driver" can store up to 10 cars, and you can assign a customized livery for each of these cars.



But it doesn't stop just there. Being an AI racing game, it is also used as a research platform for testing out various approaches of artificial intelligence, from Neural Networks, to Fuzzy Logics, and Evolutionary algorithms, among others. Countless of research papers have have been developed to accompany the approach they use, and a dedicated competition for them once existed in the form of Simulated Car Racing Championship, which was run until 2015. It was a competition between TORCS controllers of varied approaches featuring heuristic and evolutionary approaches. The 2013 competition has the documentation in the form of presentation (showing the entries and tracks used, plus the results) and race highlights above which should give you a glimpse how the competition was run. Other than that, there's also TORCS Endurance Championship which also gathers different controllers submitted online in the TORCS Racing Board community.

If following the controller tutorial above looked too hard for you, one tool makes it easier for the job: the SCR Server comes in handy in developing new controllers, using sensor and actuator models and the client-server architecture to implement them. The software extension has been used in various researches and was the main platform for the Simulated Car Racing Championship races. The SCR Server patch is available for Windows and Linux systems, with SCR Client available for C++, Java, and Python programming languages, among others. The software manual can be a good starting point on which sensors and actuators you can use for the new controllers within the client, and the SimpleDriver class included should give you a glimpse of how everything is coded for the actuator functions (i.e., how the steering input is determined, when to change a gear, how speed control works), but of course you can learn from existing papers for logics or head on here for the collection of controllers competed in SCR Championship if you want to fully learn how to.

Based on personal experience, I would recommend using Visual C++ or DevC++ for coding the C++ client and NetBeans IDE for the Java client.

THE MISADVENTURES

A glimpse of a chart about how my controller, KalmanDriver, works. The controller itself uses Kalman Filter as a means to determine the car's next trajectory based on sensor readings. The chart is actually translated from my actual presentation and added with notes to explain the notations used.

Throughout the development of my project, I have called hiatus on things I do (which I hinted a lot of times in this blog), including Instagram for instance. I swear that I actually have a thing or two worthy as an IG post but then again those factors played out and drove me off, especially looking at my friends. During this rate, I know I wasn't who I were where I can just post stuffs like people these days would do, even if, say, only one post made in a month. Site redesign, whether it's two of my blogs or my Tumblr (although I postponed it due to the bombshell already happened), was also in consideration as well with no realization during the project's time. Plus, this also took toll on some of my other projects as well, including the lack of "progress" sheet in the polling competitions I covered on Excel and the fact that I couldn't able to do the Spring/Summer 2019 Fashion Week spreadsheet in time although this absence didn't affect the previous Fall/Winter spreadsheet which saw its light of the day on March 13th.

The approach used here is Kalman filter which is the algorithm of prediction and estimation. Based on previous state, the current state will be predicted and the measurement will be corrected based on the current state, with both process include the modeling of noise from the respective systems. It is originally used to solve the Apollo project's navigation problems, and has been implemented in various fields, such as navigation, finance, and others. With the algorithm choice being set, the Kalman filter driving articles online also inspired me to go for broke in developing the controller. The concept in the articles I've read, compared to my topic, is almost, if not fully, similar in that both approaches use sensors to detect am object. Additionally, I came across one research paper (by Gomez-Gil et al) which also implemented Kalman filtering but this time the research involved a tractor and GPS sensors installed within the tractor, which would then be used to predict the tractor's trajectory. Eventually, the research paper became my eventual go-to for my controller's kinematic model.

KalmanDriver in action! Note that I didn't expect the controller to do that well in g-track-3, especially when you take account the fact that the track is notorious for its bumpy surfaces and the jump section before the final section.

Development took roughly a year with the paper itself taking almost 1/4 year in conjunction to the development. Given that I tasted different programming languages throughout semesters, re-learning languages I haven't visited is a while was inevitable, and the controller was initially developed in C++. Unfortunately, due to lack of visualization, compiler errors during run in other systems (I used CodeBlocks instead of DevC++), and myself being unable to get Visual C++ in time, a decision was made to instead develop it in Java, taking the IDE's ability to make GUI frames into account in order to have some visualization in sensor readings. At the same time, I have to search for other controllers so I can learn how the controllers are developed considering that I had zero experience in making a controller. not even the AI class I took years ago had TORCS as the curriculum.

My woes continued as I tried to understand Kalman filter algorithm and go back and forth between the normal KF and the Extended Kalman filter by following numerous articles about them pertaining its use in autonomous driving (this being one of them), and ended me utilizing Excel spreadsheets to understand the algorithm right before it became a working source code. At last, the final feature of overtaking function was conceived to make sure the controller can race with others I have gathered. Unfortunately, a combination of the function not working as expected and a failure of compiling other controllers to be used in the testing resulted in taking an unnecessary additional time, taking longer to finish the paper. As a result, I called it quits and scrapped that additional feature, as a time trial test was more than enough to serve my paper's main purpose.

Presenting the end product to the seminar (and later the defense), it turned out well, and all my difficulties stacked up during the development of the project actually gave me some edge in explaining the game, the controller, and the approach used, and I didn't have any problems in answering questions regarding to my project during both of my presentations. Even with that, I have to admit my own KalmanDriver could be made better, but nonetheless it's a good start. I wished that i could come up with more approaches on the actuator functions given that most of them were adapted from another controller, and eventually make a working opponent function so the controller can actually be competitive against the pre-installed TORCS controllers, not to mention some fixes to my own Kalman filter code. Other than that, I'm considering about making a GitHub account to store this so I can revisit the project whenever I please so that I can improve the controller anytime, and of course an international-grade paper is currently in the works.

(Note: actual presentation closing art)

And now that I've defeated all kinds of my inner demons during the devlopment and finally freed from the chains of the Bachelor's thesis I've worked, I can go back living my normal life with the new perspective I've developed...

~[R]

No comments:

Post a Comment