Enclosed is the Team 254 2011 FRC Codebase. This code is released under the BSD 2-Clause License. A copy of this license is included in the COPYING file. The relevant Chief Delphi thread is located at http://www.chiefdelphi.com/forums/showthread.php?p=1085065 Please post a comment there if you have any questions or find this code helpful. Most of the functions and classes are documented or otherwise simple and self-explanatory. The logic inside, however, has often become quite convoluted (especially as the season progressed and new features were incorporated). This is our major concern with the system but we will be working on better documentation in the future. CONTENTS: AUTHORS lists the main contributors to this codebase COPYING contains a copy of the BSD License main.cpp includes our SimpleRobot-derived class, including logic for autonomous mode and interfacing with the control board in disbaled and teleoperated modes matlab/ contains the code for our full state feedback control system. matrix.c and matrix.h are a C matrix library developed by Parker Schuh; it was chosen because we needed a library quickly and it was on hand. In a future version we would write our own C++-style library (with nice objects and methods and operators) for better code readability. scripts/ contains a short script to automate the uploading of our constants CSV to the robot. The copying script was written by Eric Bakan, the Ruby watcher was developed by Parker Schuh. RobotConfig.csv contains all the constants used by the system - PID values, preset heights, autonomous mode distances and angles, etc. Source/ contains the core source code used on the robot. Functionality is described below FUNCTIONALITY: main.cpp creates a SimpleRobot The robot then creates a CSVReader for reading the CSV file, a RobotState for storing what the robot is supposed to be doing, for getting the sensor values, setting the outputs, and helper functions for writing auto modes quickly without knowing the details, a ControlBoard for reading the joysticks and talking to the control loops, and a ControlLoops which forks a notifier and runs all the control loops at m_robot->dt. Anything which modifies the RobotState must have the robot state lock, or corruption might occur. The Reset functions are called on the robot state and control loops when the bot is initialized, and goes from disabled to enabled. The CSV file is re-read then as well. CommonIncludes.hpp includes many utility functions (converting units, etc.) AccelFilterBase, ContinuousAccelFilter, and DiscreteAccelFilter are all acceleration profile generators used in autonomous drive control. The discrete profiler was generated first because it was simpler but the continuous profile is far superior. The CSVReader is used to read constants from a file for use in the program. This enables a team to not have to redeploy code to change constants when tuning - simply modify a file on the robot and reset the CSVReader (often when enabling/disabling the robot) ControlBoard reads values from the control board, handles much of its logic (semi-autonomous actions, running filters on joystick inputs, etc. In its update loop ControlBoard updates RobotState with all its values - control loop targets, statuses of toggle switches, etc. ControlLoops/ contains control loops for each of the major robot systems. The arm and elevator run on PID loops with target positions/angles, minibot and rollers are quasi-FSMs and merely control logic, and the drive control is the most complex, handling both teleoperated driver control and autonomous full state feedback control. ControlLoops creates a new thread to update each of the control loops every 10ms. RobotState is the core of the system - it is the data structure that is passed around between the main robot, the control board, and the control loops. Since the system is multithreaded, it is of utmost importance to make sure each system acquires the robot's mutex before it performs operations. In addition to holding data, RobotState also provides some useful threadsafe and non-threadsafe functions to interface with its data members. There is limited distinction between threadsafe and non-threadsafe functions at the moment, but this is a point of improvement for us next year. Together this forms a system where main.cpp controls whether the program will run autonomously or accept user input. If it needs to run autonomously, a new autonomous thread is spawned. Otherwise if there is user input, the system tells ControlBoard to update the RobotState based on the current inputs. At the same time, ControlLoops is in its independent thread updating the robot's outputs, whether in autonomous or teleop mode. If you have any questions, contact Eric Bakan at eric@ebakan.com