Behold! AirSim is a simulated Drone and Car driving environment. It can be used to train RL/ML models. It features a comprehensive library and is generally flexible. Getting a working example set up is simply a matter of setting up the Unreal Environment.
Ok great! We have a basic example and are able to cruise around the neighborhood. There are deer and raccoons that can be periodically seen. Cars line the street and the sky is a nice blue. The car only drives straight for now and we’ll want to make some changes. This will be our first encounter with the docs.
settings.json
In order to get our screen to look like the above image, we’ll need to update our settings.json file. Let’s consult the docs and determine the file location.
I’ll save you some time and reveal that it’s in none of those areas! We can do a quick search of the GitHub repository to try and get some hits.
Here, we see two settings.json files. One under a docker directory and another under an azure directory. We’re currently using the Unreal Environment and so are not utilizing docker to run AirSim. Likewise, we’re not sending nor receiving data from Azure so that settings file is out. It is at this point that a person might take to google to try and resolve this information. AirSim is fairly new so there isn’t a whole lot of information out there aside from the API documentation. This also means that general questions haven’t been answered yet. Time to pour over the docs for an hour only to realize that beneath that list, outside of the numbering system.
This is closer, however, on my system, it was not located in the home directory. I’ll save you a bit more time and indicate the file path here. On Windows my settings.json file was located here: C:\Users\Admin\Documents\AirSim. This is certainly not the home directory! For a new user, this can be incredibly frustrating!
So what?
This wasn’t the only example of incorrect information sprinkled throughout a mostly accurate document. That was the hardest part. The expectation was established that you could generally follow the guidelines and get by. This highlights why documentation should be valued and if the decision is made to document work (which it should be), then time should be set aside to both write and have someone proofread the document.
I’m willing to bet that the documentation was correct at some point. Someone (hopefully someones) took the time to go through the code and create a pretty great document. As changes to the code happened, the documentation was not updated and a slow, but steady separation began to form. The main criticism against using the AirSim environment is that the documentation is a bit lacking. My experience has reflected this so far.
Going forward, I’ll keep this experience in mind and do my best to facilitate the easy acquisition of knowledge when using something I’ve created. Hope this has given some useful insights 😀
