Software Tutorial 04: AI Basics

Now that you have the code downloaded and compiled, it's time to start working with the AI. But before actually coding, it's important to understand some of the basics of our system. Our AI uses two state machines nested inside of each other that are used to split the numerous challenges into more solvable pieces.

Tasks

The first state machine cycles through objects known as Tasks. These Tasks represent each of the challenges we have to do for the competition. For instance, there is a task for firing both torpedoes through a target, or hitting some buoys in the right order. The robot will execute a series of these tasks, specified by a configuration file.

All of the tasks are defined in the course.py python file in the AI folder. Some of them look pretty complicated, but for simple tasks, this code is not necessary. The ordering for the tasks will be in the AI config file for the robot, whichever one it is using.

States

To simplify the design process, we then split each of the tasks into states. States represent a small step of the overall task. For instance, diving to a specific depth and then moving forward through an obstacle would be two separate states. The states for a specific task are defined in a python file with the task name, such as gate.py or buoy.py.

When designing a task, we often draw out what is called a "state diagram". This is essentially a graph that shows all of the possible states, and how they would transition into each other. From a state diagram, it is very easy to write the state: just create all the state classes, set up the transitions, and then fill in the necessary body code.

States have a couple of core features. States have built in configuration values, which can be changed on the fly via a config file. We usually use these whenever we have state specific-constants that need to be defined. States also have a list of transitions that determines which state should be executed next, and when. In addition, states have over writable functions which are called when entering or exiting the state, as well as when events are triggered.

Events

Our AI code is entirely event based. There is no update loop, so code can only execute when an event is triggered. Events come from many different sources, such as the motion manager or the vision system. Events also usually give you additional information about what is going on. For instance, vision events will tell you the location of the object on the screen, and what color the object is. It is also possible to come up with custom events, for the purpose of switching to a certain state.

Events can trigger two things. The first thing that events can trigger is a state change. When an event is triggered, it looks up which state it should transition too, and then switches to that state. The other thing events can trigger is a callback method. Essentially, this causes a function with the name of the event to run, allowing you to run code whenever a specific event is triggered.

Software Tutorial 05: Config Files and the Simulator