Team Three/Final Paper
Contents |
Intro and Goals
The main goal we had going into the competition was to try and keep it simple. We recognized that our team did not have people with mechanical engineering experience. As a result, we made sure to pick modest scoring goals (pick 2 out of 3 scoring methods). We also kept our mechanical design modular and simple (a claw and a shaft). Software was more complicated.
Mechanical Design
Overview
Our design consisted mainly of a claw-shaft mechanism to stack the cubes. The claw would grab cubes and deposit them in the shaft. Then, once the shaft contained a stack, it would open up, letting the stack move to the floor. Then, the robot would drive away, leaving a stack behind it.
Claw
The claw of the robot had two main rotating parts controlled by two servos. One servo rotated the entire claw rig so that once the robot grabbed a cube, the claw would rotate backwards so that the cube could be deposited in the shaft. The other servo opened and closed the claw to grab a cube. The claw itself used rubber bands as a grabbing mechanism - when the claw closed, the rubber bands would stretch and form around the cube, keeping it secure.
Effectiveness
The claw design was designed to close from the top over a block. This gave us the capability to remove blocks one by one off of the stacks. Unfortunately, this also meant that we couldn't just drive into stacks and pick up blocks; we needed to aim our robot precisely to be in a good position. Although in the end, our claw worked, it required a lot of fine tuning on the software end, which was undesirable. A better design may have been to have a claw which grabbed cubes from the side, rather than the top, which would allow us to just run into stacks and pick up cubes (since the claw would be self-aligning). However, this would have removed our capability to unstack cubes precisely without knocking over the tower.
Shaft
The shaft was located in the back of our robot so that after placing a stack, the robot could drive away without knocking over the cubes. Originally the design was to have the shaft made up of two almost symmetric pieces - each piece would have two perpendicular walls, and one of the pieces would be attached to a base. One of these pieces would open up to allow the stack to move from the base to the floor, and then the robot would drive away. Later, we modified this slightly to ensure the stack wouldn't fall over when released. We disconnected the base from both pieces of the shaft and had it rotate away from the shaft walls first. This made it so the stack would then be on the floor but still be surrounded by the shaft walls, keeping it standing. After this, one shaft wall would rotate so that the robot could safely drive away. To make sure the claw actually dropped the cube into the shaft, we created a funnel out of cardboard to direct the cube into the shaft hole.
Effectiveness
The shaft worked well in the end. Sometimes a cube would get stuck on the sides of the shaft; in that case, we had to "wiggle" the openable part of the shaft walls to get the cube to drop. This only occurred once every 10 blocks or so and wasn't a big deal. The dimensions of the shaft were such that blocks always landed flat on top of each other; a shaft too large would allow cubes to fall crooked onto the stack and have a corner get stuck in a hole in a lower cube.
Chassis
The robot body consisted of two layers, a base plate and a top plate. The top plate had mounts for the camera and the claw. The back connectors between the base and top plates had mounts for the motors, and holes for the wheels to fit. The drive wheels were located in the back, and one caster wheel was located in the front. The back of both plates had a hole for the shaft, with room for the shaft wall to rotate. Servos were attached to both plates for the shaft rotation. Sensor mounts were placed all over the chassis so that we could easily change the location of our sensors if needed.
Effectiveness
The main driving wheels being in the back of the robot made it difficult for the robot to navigate successfully through the map; however, the placement of the drive wheels allowed us to be confident that we would be able to drive away from the stack without running into it (since the center of the stack was over the center between the drive wheels). Also, our robot did not have rounded edges, which led us to getting stuck on a wall in the final competition. Our robot probably also could have been smaller.
Software Design
Localization
Pathing
Vision
The image processing worked as follows: After the initial camera capture, the color data was put into an OpenCV matrix and converted to HSV. Then, the matrix was filtered by hue, whether the blocks it sees are green or red. Because this is a fairly noisy process, a series of morphological operations were used in order to clean up the noise, and dilate whatever is left to the size it would have been prior to the filter. This was very effective, and left a nice and clean binary matrix behind. OpenCV has an inbuilt function to find blobs in a matrix and report its center location and area onscreen, and using this data, the absolute position of the blocks could be derived.
However, all of these bitmap operations took roughly half a second of computation time to complete, which is unacceptably long. In order to optimize, and prevent the program from iterating over all 480x640 pixels, we reduced resolution by a factor of 2 in each dimension, reducing the time taken to approximately 0.1 seconds. I fear that this should have been halved one more time in order to reduce lag even further. Through trial and error, we found that the screen resolution could only be changed by factors of two, though the reason why is anyone's guess. Other potential optimizations include rolling our own BGR filter to eliminate the need for one of the three bitmap operations, and using flood fill algorithms to determine location and size of blocks, rather than filtering at all.
