For our latest Cool Project, we have guest bloggers, Team 8086A – Team Semiconductors to discuss their unique dual-bot for last year’s VEX Robotics Skyrise competition. They went on to win the 2015 World Championship Science Division Create Award! Read more below.
For the 2014-2015 VEX Robotics game, Skyrise, Team 8086A, Team Semiconductors, built a very unique robot, a dual-bot. This robot’s unique design included many advantages, most significantly the ability to multitask. However, along with the advantages came many challenges. The team worked hard all year to conquer the challenges and the assistance of ROBOTC in many of these challenges was invaluable.
Team Semiconductor is a group of friends in Glen Allen, Virginia. This independent team has its roots in two middle school VEX World Championship competitive robotics teams, Team Theodore (6740C) and Team Dave (6740D). Several students from the two teams and their school’s Technology Student Association (TSA) who were moving on to high school and wanted to compete in VEX Robotics banded together to create a new team, Team Semiconductors. Midway through the 2014-2015 season (Skyrise), the team revealed their one-of-a-kind design: Arty the Dual-Bot.
Skyrise was the 2014-2015 Vex robotics game. The goal of Skyrise was to build a skyrise (a yellow pylon, built piece by piece). 4 points were awarded each section built, and putting cubes (hollow cubes, 8 inches wide) on the skyrise were worth another 4 points each. Then, you could put the cubes on varying height poles for 2 points, and if you had the top cube on the post, you scored 1 extra point. This was the tallest game vex had ever made. The highest item was the robot built skyrise which at max was about 60 inches tall.
Arty: The Dual-Bot
Arty is a very unique robot designed to compete in Skyrise: a dual-bot. Arty consisted of two parts each performing specialized tasks simultaneously: an immovable tower that is dedicated to building a skyrise, and a rover, whose task is to move around the field placing cubes on poles and on the skyrise. These two pieces have a connector running between the two holding the wiring, and they also give the robot its name, “Arty” (RT for Rover/Tower).
Team Semiconductors had multiple reasons for using a dual-bot. The most important reason was the ability to multi-task, which allowed for higher scoring and the ability to still compete if our alliance partner is a no-show. This bot was made possible due to the high scoring potential in the starting area, with scoring skyrises. We noticed that many robots that would do skyrises wouldn’t even leave the starting square for the first minute, while stacking skyrises. We thought it would be best to have a stationary robot in there to score those while another part of our robot was doing something else. One of the biggest advantages of the stationary tower was its precision; instead of relying on time to move the skyrise, we could use potentiometers to measure the position of our claw, and drop the pylon once it lined up.
Arty can score high by itself in matches, up to 58 points on its own without autonomous bonus, allowing it to be able to carry most matches, regardless of alliance partner. It also has high skills scores, with the second highest Driver Skills and Programming Skills scores in Virginia, with 43 and 27 points, respectively.
Two main factors came into play for us choosing ROBOTC to program Arty: it’s easy to learn and it has the ability to use tasks. The first factor was essential, as our team had no previous experience in ROBOTC. The only previous experience with programming robots our team had came from using block code. The transition to using a text-based language, especially one we had almost no base in was worrying, and lead to questions about our ability to learn the language in-time to program the robot. Our lead programmer had experience in programming languages, but no experience in C-based languages, meaning there was a lot of learning involved in the first few weeks of programming. However, after those few weeks, we felt confident in our abilities with the program, and were able to create the complex programs used in Arty with almost no syntax trouble.
The second factor was specific mainly to Arty, but still very important. Due to Arty being a dual-bot, we needed a way to run programs for the rover and the tower at the same time. This was allowed by tasks, which can run side by side with each other, unlike functions, which run one after the other. These tasks allowed us to run the rover and tower side by side, but also allowed for smaller additions to increase efficiency.
How ROBOTC was Used
As mentioned above, one of the key elements of our programming of “Arty” was the use of tasks for the control of both rover and tower. We used separate tasks in both driving and autonomous functions. We also used tasks to increase efficiency in our programs. For example, we used tasks to turn the tower arm and raise the tower simultaneously instead of one after the other to save time. One problem we came up against with tasks was the inability to pass inputs into the tasks. To get around this we created functions that modified global variables and then called the tasks, and used those global variables for things that would’ve needed to be input into the task.
One of the most interesting things we did in the rover’s drive tasks was creating a turret-centric drive. The turret on rover that could swing 360 degrees was always facing forward on the robot. Since we had an X-drive, any direction could be the front of the robot; it was all in how we programmed the wheels. One of the biggest problems rover had was its inability to turn without getting tangled in the connector. We put a turret on the top of the robot to prevent us from having to turn, but this made driving awkward. The solution to this: a turret-centric drive. We measured the location of the turret with a quad encoder and adjusted the values in Robot C according to which way the turret was facing. This made it so that whenever we hit up on the joystick the rover always drove in the direction its turret was facing, making it much easier to drive, since it now had a distinct “front”.
In programming our tower, we found that we were always doing the same thing, but we were just changing times for movement, and target locations to account for swing. To save time and space in our program we used a for loop that looped for however many skyrises we were going to build. At the start of the loop we had a switch statement to assign all the values based on which piece we were stacking. We then had our previous generic code that we had been writing out inserted, with variables instead of numbers being used. This saved a lot of time in programming, as all values that needed to be adjusted were easily found in one place.
Due to the way the tower was built, sometimes our arm would get caught on something, and not finish the turn. To get around this our turn function had a self-check built in. At the start of the task, we would calculate approximately how long it should take for our arm to reach its position. At the end of the time period, we would then check to make sure we were in position. If we were not, we’d raise our arm and then try to turn again. This process would repeat for 3 times at most. If it reached its location, it would then lower the arm the same amount it raised it and continue the program. If it never reached its location it would set a variable to false, and then the program would stop, to avoid wasting scoring objects by dropping them.
ROBOTC helped the team maximize our unique robot design and Team Semiconductors went on to win the 2015 World Championship Science Division Create Award with Arty the dual-bot. You can learn more about Team Semiconductors and follow us on social media at http://www.VEXTeam8086.org.
Test Your Skills with our Virtual Competitions!