Sanity Check invalid Subsystem Parameters

[max-49]

Integer division vs double division

[cowsed]

when starting a new repo and youre robot config is all zeros, the robot can silently fault with division by zero errors and the brain gives no error report. If we assert that all parameters are valid, we can print out our own errors for these hard to track down errors

[cowsed]

We might want to write our own assert function that prints to the screen or controller in addition to stdout so its really hard to miss

[cowsed]

FOR THE NOTEBOOK ENTRY, YOU CAN COPY THIS FOR YOUR IDENTIFY THE PROBLEM. Do make sure to read it first though.

A VEX Robot is a highly configurable system. Each subsystem on the robot can have dozens of parameters that control its actions and, when any of these parameters are not initialized properly, the robot can behave erratically or even silently crash with a divide by zero error. In the excitement of getting new hardware to work with and under time pressure, it is easy to not fully initialize all subsystems - especially ones that are not under test at that point in time. As well, C++'s sometimes subtle casting rules can have a programmer unknowingly passing a zero when they instead meant to pass a fraction. To save programmers from pulling out hair in frustration, validity checks can be inserted on construction of these subsystems that warn for invalid or illogical parameters.

The following classes have been identified for validity checks:

• PID Controller Config
  • While it is possible to have kP, kI, or kD be zero, if all of these parameters are zero, the controller is probably not set up correctly and a warning should be issued.
  • If deadband is zero, the robot will likely never reach the target and the PID controller will never report being done leading to the stall of any autonomous functions. This is not acceptable in match play so a warning should be issued.
• Feedforward Controller Config
  • While it is possible to want any of kS, kV, kA, or kG to be zero, if all are zero the controller will not contribute anything to the actuator and the user should be warned of that.
• Take Back Half Controller Config
  • If the gain parameter of the controller is zero, the controller will do nothing. A warning pinpointing the position of the error will aid in quickly remedying this.
• Motion Controller Config
  • The max_v and acceleration parameters define the physical limits of the robots movement. If these are left uninitialized the motion controller will not be controlling any motion.
• Robot Specifications Config
  • If odom_wheel_diam, odom_gear_ratio, or dist_between_wheels a divide-by-zero error will occur or any amount of movement will read 0 movement to the subsystem. If these are uninitialized, the user should be warned.
  • If drive_correction_cutoff is zero, the robot will turn wildly towards the end of it's drive movements - it will try to fix small errors with large, usually unhelpful spins back to drive toward the target. This can be very unintuitive behavior to debug so validating this parameter will be helpful.