Skip to content

Structure of the codebase

Jump to bottom
Nicklas Boserup edited this page Aug 17, 2017 · 4 revisions

The source code is located under ./frc2017/src/org/usfirst/frc/team6678/robot/

File tree

  • Robot.java
  • Log.java
  • CustomMotorDrive.java
  • Driving.java
  • WebServerHandler.java
  • backgroundTasks
    • BackgroundTask.java (interface)
    • BackgroundTaskHandler.java (Singleton)
    • ButtonSwitchState.java
    • UltraSonicDistanceSensor.java
  • autonomous
    • Autonomous.java (interface)
    • AutonomousHandler.java
    • Turn.java
  • simulations (solely for testing purposes)
    • AccelerationTest.java

Robot.java

This is where the program starts executing from. It is responsible for initializing all of the other classes. It is in this class that the main loop is located (although the actual main(String[] args) is located deep into the WPILib framework).

Driving.java

Handles a higher level control over the motors of the robot. It is used directly by the Robot.java class, whilst the robot is in tele-operational mode.

CustomMotorDrive.java

This class is responsible for low-level driving mechanics. Things like:

  • Communicating with the physical motors
  • Acceleration and deceleration
  • Various methods for controlling the robot

The class is a more complex and customized replacement for the RobotDrive class, from the WPILib.

Autonomous

Classes located in the autonomous package, org.usfirst.frc.team6678.robot.autonomous.

All classes in this package are for controlling the robot autonomously. It includes some helper classes to make it easier to make the robot run autonomously.

AutonomousHandler.java

This class is responsible for handling autonomous controlling of the robot. It is directly referenced in Robot.java when the robot is in autonomous mode.

BackgroundTasks

Classes located in the backgroundTasks package, org.usfirst.frc.team6678.robot.backgroundTasks

All classes in this package, is for handling miscellaneous background tasks, like retrieving sensor values etc. It also contains helper functions used for driving mechanics, among others.

General Guidelines

  • Please keep the number of threads to an absolutely minimum. If background threads are necessary, combine all the tasks that need it in one thread. This may be done in a similar manner as the BackgroundTaskhandler Singleton handles every BackgroundTasks.

  • Please divide code into multiple logical classes, and collect these in appropriate packages to help keep this project neatly organized - even when it grows increasingly larger in the future.

  • Please document your code carefully. Not what every line of code does; we do understand that part. But please describe what every class and method is designed to do, and maybe with some explanation of how it might be used. Also make sure to use the general JavaDoc syntax with descriptions of the methods, parameters, and return-values. This helps to make it easier to understand the broader context of the code.

  • Please provide plenty of logging from your code, anywhere where it may make sense. This helps troubleshooting tremendously and has already helped us fix some unintended bugs. Be aware of the different levels provided in Log.java.

  • All the code called from the *Periodic() methods in Robot.java needs to be executed in no more than 20ms - and preferably a lot less. Therefore, background threads are a necessity in some cases, eg image processing, and web server requests. Essentially all the code that is not processed in a separate thread need to be able to be performed in less than 15-20 ms.

  • Rather provide a little too many sanity checks than a little too few. We do not want any potential crashes due to uncaught or unprevented exceptions. This is arguably even more important on a (partially autonomous) robot, than in some desktop application. Pay particular attention to any possible null pointers, and begin the sanity checks with a check for a null reference, since the boolean conditional operators are short-circuited as mentioned in the gotchas article.

  • TODO: We need to decide whether or not to gather sensor inputs constantly, even when we do not use it immediately (if at all). Should we eg be fetching data from the Ultrasonic Distance Sensor, even when not directly using it? I think we should, but this needs a decision!

Clone this wiki locally