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.
Original goals:
- Determine specific hardware parts (motors, shields, etc) by 1/7
- CAD every part of the robot by 1/11
- Initial workingish prototype by 1/14
- Have autonomous code for the prototype by 1/16
- Finish actual robot (mechanical portion) by 1/21
- Finish debugging and testing everything by 1/28
We mostly met our hardware goals. However, we weren't able to get two separate robots out (the early prototype didn't happen) which led to our software team being sad.
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
Our robot performs Monte-Carlo localization with a particle filter to determine its location and orientation. It uses readings from four IR sensors, one on each side, as input. At the beginning of the match, it reads in the input map and stores the initial location of the robot and the locations of the walls. Since we do not know the starting orientation and only know the starting location to an accuracy of 6 inches, we need to use input from the IR sensors to determine our state. At the beginning of the match, we generate 10000 particles of different orientations near the given initial position and compute their likelihoods given our IR readings, and sample 200 particles from them. Then, as the robot moves, we update our particles using odometry data (encoders and gyro) and resample them based on new IR data.
Pathing
At the beginning of the match, we divide the map into a grid with 12"x12" cells. We mark cells near walls and near where we plan to deposit completed towers as impassable, to avoid running into them. After the robot knows where it is, it does A* to path to the location of the closest block that has not been picked up. To avoid paths with lots of turns, we add a distance penalty for turning.
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.
Conclusion and Advice
Overall, MASLAB 2015 was a great time for all of us. We learned a lot about mechanical design, software design, and project management. Our downfall was probably not sticking to our timeline and not leaving enough robot time for programmers to iron out all bugs in the software.
Advice to teams:
- THE FINAL COMPETITION MAP HAS A BUMP/SLANTY BIT AND THE TILES ARE PRETTY SLIPPERY!! :( :( Use high enough power to account for this and don't have robot bits which are really close to the floor.
- STALL DETECTION is really necessary.
- Test ALL edge cases.
- Stick to the schedule you make, and try to clearly identify tasks as the team goes along.
- Your robot probably doesn't need to be as smart as ours tried to be. Just try to get your robot to gather things before trying to devise fancy plans and strategies.
- Pick a subset of possible scoring methods because you won't be able to design a robot that will do all things in time.
