Project for CPSC 424/524 "Intelligent Robotics"
A robot that navigates a terrain autonomously to avoid zombies 🧟 and pursue fuel 🍓 in Webots simulation by implemeneting a global DAMN voting architecture and a local subsumption architecture in C.
First install Webots if you haven't done so. Then choose a world. Then start the simulation and the robot will start running!
Our overall strategy for survival is going in the most promising direction at any time. In terms of sensor choices, we use 4 cameras--front, back, left, and right--such that we get a corresponding image in each direction. We parse each camera image to obtain a value associated with that image. The robot then goes in the direction with the highest value image. At a high level, this architecture is DAMN, where each behavior (go forward, go back, turn left, and turn right) votes, and the vote is weighted more heavily when the associated image's value is higher. The robot chooses the behavior with the most weighted vote. We recognize that the 4 images don't cover the whole 360-degree view, but we also observe that the "blind spots" won't cause significant trouble because the robot tends to keep moving instead of stopping (see below), and the likelihood of zombies staying in the blind spot is low, especially with closer zombies.
To obtain a value associated with each image, we employ two design principles. We 1) leverage a command fusion model for high level navigation and 2) complement it with a local subsumption model for zombie/wall avoidance and berry pursuit. For each of the four directions, we determine a value for that image through a linear combination of the objects present in that camera image. For each type of berries, zombies, walls, stump etc, we give corresponding weights that captures their benefit to the robot. Specifically, the value of an object in an image is roughly proportional to the fourth power of the difference between its bottom coordinate and the center, and also proportional to the pixel distance of its center to The more positive the aggregate value, the more beneficial moving in that direction would be. However, even after extensive weight tuning, there are situations in which the robot doesn’t avoid imminent threats. For instance, an image containing multiple berries with a close by zombie might result in a weighted sum that is comparable with an image containing no objects of interest (i.e. just a tree in the background). Command fusion on its own is not aware of the correct action--evading the zombie. Therefore, we implemented a local subsumption architecture so that the robot recognizes the presence of a zombie and escalates by overriding the current movement with a command to evade the zombie. Specifically, if a zombie is detected to be close by, or a berry is detected to lie in the center of the camera image, or a wall is detected to block the way the robot is moving, then we make sure the robot is behaving in the desired way by suppressing the output of the command fusion architecture. The local model always subsumes the high level model.
The robot keeps track of the berries it has eaten and these berries' associated effect in a table. Based on the empirical counts of each type and its effects, the robot updates weights for berries such that it prioritizes berries whose main effect (determined based on effects with more empirical counts) is adding energy / health especially when its energy / health is low, and avoids the type of berry whose main effect is losing energy. Additionally, the robot uses its arm to push berries off tree stumps when it's close to a stump; this behavior has low priority, so it's only done when the robot has energy and health > 80, and is not being chased by zombies (when local best direction returns -1). To address different colors of zombies, we assigned different negative weights: -2.5, -4, -3, -2 for AquaZombie, PurpleZombie, BlueZombie, GreenZombie, to reflect their danger level and obtained these relatively well-performing values after some experimentation.
An interesting technical challenge is parsing camera information. Here's how we do so through the parse_camera function.
The function takes in an image and the image width, and first iterates through the image pixel by pixel to create a 2D array of the image, where each element of the array corresponds to each pixel. Each element of the array contains the HSV values converted from RGB; having HSV values in addition to RGB are helpful for distinguishing different objects' colors and thus their types when we have varying degrees of lights in the world. Given the 2D array, the function iterates element by element, and when it encounters a special hue (defined by ranges corresponding to zombie / berry / stump / wall / boundary wall colors), it conducts a DFS to find the connected pixels (pixels with similar hue values, meaning they most likely belong to the same object) and marks them as visited along the way; during a DFS, it also keeps track of three variables: 1) the bottommost pixel location thus far; 2) the leftmost pixel location; 3) the rightmost pixel location. The first variable will help the robot to evaluate the distance of the object (the greater "bottom," the close the object); using the second and third variables, the robot can evaluate the direction of the object. Based on the hue value, the function also identifies the type of the object.