Sunday, February 22, 2015

Time Began in 1970

When I was doing the first autonomous test drive of our robot, I found that no matter what I did, it always flew off in a particular diagonal direction, no matter what the inputs were. When I tried to get more information about the speeds the motor controllers were calculating, I found that I was getting massive numbers around negative two billion. This meant the robot was trying to move at billions of meters per second backwards in both the horizontal and vertical axes. Fortunately, our motors have a limit of around 10 meters per second, let alone the 1000 times the speed of light they were trying to go.

At first, I had thought that this might be an integer overflow issue. In most programming languages, integers that reach a certain maximum value wrap around into the most negative possible value, as demonstrated by the circle below.
Found at https://log0.wordpress.com/
If you traverse counterclockwise, you reach a very large positive number, then instantly find a very large negative number. My hypothesis was that the code was calculating massive velocity values incorrectly, and looping around into the negatives where for some reason it worked fine.

I soon realized that the problem was something entirely unrelated to integer overflow. First, that the values used to track the velocity of the robot are 'doubles', which have a different max value than integers. Second, although the velocities were suspiciously close to the -2147483648 of negative integers, they started at a value only coincidentally near it.

So after many more hours of debugging, we finally found the error: as far as the robot understood, it had been driving in a diagonal line since the first moment of 1970.

Time in the world of computers is measured by UNIX Time, a count of the number of seconds since 00:00:00 1/1/1970 Coordinated Universal Time (UTC). This has led to joke sayings such as "time started in 1970" or "everything before 1970 is made up." The advantage of UNIX time is that it allows time measurements to be consistent to a second across all computers, and for higher level programs to generate dates and calendars in a consistent way.

However, what day it is shouldn't have any effect on the robot's driving, it only needs to know how long it's been since it started. Because the time was never shifted into relative numbers, the robot was attempting to undo 45 years of driving. The drive correction loop is proportional, so the correction velocities were very large.
http://xkcd.com/376/

Friday, February 13, 2015

An Introduction to FRC and Autonomous Robotics

Welcome!

I am a member of FRC Team #4183, also known as Bit Buckets Robotics. We are a local Tucson team consisting of an extremely talented group of High School students and mentors. As a team, we focus on finding the most effective solutions to the engineering and design challenges we face.

We participate in the FIRST Robotics Competition, which is a world-wide robotics competition design to give high school students a taste of real world engineering.
The varsity Sport for the MindTM, FRC combines the excitement of sport with the rigors of science and technology. Under strict rules, limited resources, and time limits, teams of 25 students or more are challenged to raise funds, design a team "brand," hone teamwork skills, and build and program robots to perform prescribed tasks against a field of competitors. It’s as close to "real-world engineering" as a student can get. Volunteer professional mentors lend their time and talents to guide each team. -FIRST
 Competing in FRC is a task which requires a team to excel in many different fields - CAD design, electrical engineering, fabrication, computer programming, robot driving skill, graphic design, project management, organization, fundraising, obtaining sponsors, networking. I personally am part of the programming team, and most of my time researching, writing, documenting, and testing code which will run our robot.

While programming a robot is the job of multiple people on our team, I personally am in charge of programming the autonomous side of the robot. This years FRC competition requires the robot to operate without any user input for the 15 seconds of the match.

Autonomous programming is something that many teams fail to complete to a reasonable degree - some because they run out of time programming other parts of their robot, or some because they do not understand an effective way to go about it.

The goal of this Senior Project is twofold: first, to learn and program effective autonomous operation on team 4183's robot, and second, to teach and assist other teams in attempting autonomous operation in future years.