Robotics 2011-2012

This will discuss only the building and programming aspects of my experience in robotics in 11th grade. Compared to last year, we had much more trouble building the robot, but I feel the end product is much more sophisticated and functional.

This year’s game is essentially basketball. The game starts with a 30 second hybrid mode, where robots on a team attempt to score basketballs automatically or while being controlled by a Kinect (which is pretty random). The robots can be controlled by humans for the next 2 minutes, where they once again attempt to score. The final moments of the match are fairly unique – the robot has to attempt to balance on a pivoting bridge. It makes more sense when you watch the video.

We decided to create a 6-wheel robot that scoops in balls through an opening in the front, shoots it using 4 spinning wheels, and can target the backboard with a camera.

The code is much better then last year’s. Although I’m still in the process of writing the code and can’t be fully impartial, I don’t feel the faint sense of uneasiness that I had last year, if that’s any form of indication. This code was written without the help of any mentors between me and another student on our team (who probably wants to remain anonymous).

It essentially splits the code up into several tiers:

• WPILib objects – Objects that interact directly with specific pieces of hardware (provided by a 3rd party library)
• Components – Objects that control specific subsystems of the robot, such as the shooter
• Controllers – Objects that convert user input and control the robot in many different ways
• MainRobot – A singleton class (is that the correct terminology?) that ties everything together.

By deliberately separating the code needed to interact with a hardware subsystem and the code needed to control it, we were able to experiment a lot more compared to last year – it became trivially easy to swap tank-style driving with arcade-style driving, for example, by simply commenting out one line. The code was also less bloated compared to last year – instead of having every single constant be stuck in a single file, they could be contained in their own class definition.

The current issues I’m having is primarily with the vision tracking code – the camera has a fps of 2 per second, so constantly checking the camera to see if it can detect the backboard results in absurdly long delays. When this is combined with the fact that the robot cannot always detect the target, the robot could potentially become unacceptably slow as it repeatedly tries to check for the target. I’m attempting to place the code for tracking into its own thread, but I’m having difficulty figuring out how to do that (especially given the sparseness of the documentation).