Team Eight/Final Paper
Contents |
Software
All of the software was written in C++. The code can be found here[1].
High Level
State Machine
We had 7 states: initializing, searching for stacks, driving to stacks, lifting the stacks, searching for the platform, aligning with the platform, and dropping our stack on the platform. Each state first took in the sensor data, determined the next state, then either returned a different state or ran a process (such as turning a few degrees to find a stack).
Image Processing
We used OpenCV to identify stacks and the platform using similar algorithms. All of the colors were identified by material properties found experimentally. After filtering by color, we used the findContours methods to identify the stacks, then we applied size filters to get rid of noise. Once we identified the stacks or platforms, we calculated the angle to the object to feed back to the robot for driving.
Low Level
Sensors
Distance: We used 3 medium range IR sensors (rated for 10-80 cm) to get our distance from walls and stacks. We had one on the very front of our robot and one on either side. We could use the front and any one of the sides to follow walls around the field, and we also used the front one to determine if we were lined up with a stack or the platform. These were decently accurate within the specified range and worked for our purposes.
Orientation: We used a gyroscope to determine our angle and turn towards the stacks and platforms. The gyro was very accurate and allowed us to turn to precise angles very nicely.
Breakbeams: We had two IR breakbeams on the interior of our robot to detect when our lift mechanism was at either of its two extremes. These were extremely reliable once the hardware was lined up to trip them correctly.
Alliance Switch: Finally, we had a switch on the side of our robot that deteremined whether or not we would search for a stack that had a red or green cube on top. This was important because we needed the top cube to be our side's color to get the points on the scoring platform.
Actuators
Motors: There were 3 motors on our robot, all with encoders. Two of them drove the wheels and one was used to drive the lift. Although we could read the encoder values, we did not end up using them.
Servos: There were 4 servos on our robot, two to actuate the front doors and two to grab the cubes.
Interface
The controller on our robot was an Intel Edison on an Arduino Breakout Board with an added on PWM shield. To communicate with the hardware, our firmware used libmraa. We then wrote classes for all of the actuators and servos that used the lower-level commands provided for us.
Hardware
Our robot revolved around the lift and horn assembly that captured and lifted cubes into the robot. The lift and other related mechanisms worked together to capture, condition, grab, lift and store the cube stacks.
Our robot had two identical servo-actuated doors that could turn 180 degrees, from pointing in the motion of travel to fully folded backwards. These doors had two main purposes, capturing and conditioning cube stacks. When seeking a cube stack, the doors opened partway, forming a large V-shaped funnel at the front of the robot, compensating for some inaccuracy in vision. The doors increased the capture cross-section of the robot, helping us get stacks easier. Once the stack was captured, we had to condition it to orient it properly with respect to the robot. We accomplished this by gently turning gently back and forth, knocking the cubes into alignment with several nudges.
The lift mechanism on our robot supported 2 servos which gripped the bottom cube of a stack. Once the cube was in position, the servo horns swung towards the cubes, holding it by the hole. The lift then raised the stack into the horn assembly. The lift was made from precision milled aluminum blocks with hardened steel shafts and high quality bronze flanged bushings. The lift was powered by a 30:1 polulu gearmotor with an encoder. The torque of the motor was transmitted to the the lift carriage (the part that moved) via a MXL (.08" pitch) 6mm wide timing belt. The timing belt was attached to the carriage with a waterjet "comb" of aluminum with little cutouts that matched the valleys of the timing belt. This provided accurate positioning and strength. Although the lift was equipped with an encoder, counting encoders counts was not accurate enough to keep the carriage from hitting the top or bottom of the lift. In order to prevent damage to the motor and lift, we used two infrared photogates (breakbeams) to tell the Edison when the lift has reached its maximum travel.
Horn Design
We decided to design a horn to hold the cubes that we lifted. This way, once we made it to the platform, we could place the cubes on the platform without allowing the other team to potentially knock the stack over. The horn was designed such that all 15 cubes on the game field could be stacked and stored inside. Near the end of the round, we would drive to the platform, release the lift and score our points. The horn mounts to the robot on top of the top layer with tabs, and underneath the third layer with more tabs. At the bottom of the horn we 3D-printed a flange to funnel any misaligned cubes into it. We also lined the inside of the horn with slippery tape to facilitate easy movement up and down.
The horn was decorated appropriately with money symbols running up and down it, and the words “Do You Even Lift?” on the back. It was certainly an obnoxious design.
Door (Conditioners) Design
An interesting problem we encountered as a consequence of our approach to the game of cube stacking, was the assurance of correct cube/stack orientation (i.e, how do we ensure that the robot approaches the face of a cube stack as opposed to the edge of the cube stack?). As a result, the idea of creating "doors" came up, and these doors were supposed to condition the stack to ensure that our robot approached the face of a stack, and not an edge. The idea was this: There would be two doors attached to the left and right side of the front of our robot. These doors would swing out when the robot approaches a stack and then the robot would gently rotate left and right, therefore using the doors to gently tap the cube stack back and forth, until it's face was aligned with the face of the robot. The design was as follows: Since our robot was multi-layer, the doors attached to the bottom and 2nd layer of our robot, giving enough clearance for the floor at the bottom and for the flange and lift mechanism at the top. The doors were attached to a mount (fancy word for a piece of MDF) by a door hinge (so that they could freely pivot). This mount was in turn screwed into the base layer and extended all the way through the second layer of the robot. Attached to this same mount (at the second layer) was the servo mount. On this servo mount, we mounted the servo (crazy, right?) that would control the motion of the door, and then we attached the servo horn to the door itself. So in summary, a servo at the top of the door controlled it's motion, while the hinge at the bottom of the door provided stability and support. This whole contraption was then mounted onto the first layer (or bottom layer) and second layer of the robot.
Advice for Next Year
-Have multiple programmers and don't underestimate the importance of vision. -This is a software game. We had CNC milled precision aluminum pieces all toleranced to within .001", waterjet-cut aluminum plate, and titanium sheet metal on our robot. The winning robot was made predominantly out of cardboard, and they schooled us because they had wicked good vision processing. -Get vision going ASAP, it is your most important tool. Also, use interlocks, as in, don't stay in one state/task for too long, set a timer, this prevents you from chugging into the fall indefinitely. -Know your tools and tailor your strategy to them. In other words, understand the specs of the sensors, camera, and even people you're working with, and let your strategy be one that can be executed as perfectly as possible with the given tools, materials, and team members. If you have crappy sensors, do not rely heavily on software; instead, let your hardware team take the blunt of the strategy execution into consideration when creating their design. However if you have great sensors, then you can rely more on software and less on hardware. -The fewer moving parts on your robot, the better for you. -Simple is good. Simple is really good.
