Motor Controller Management and Drivetrains - MontclairRobotics/cyborg GitHub Wiki

Like all FRC/FTC software, Cyborg has no direct interaction with motors themselves. Instead the software deals with the motor controllers and feedback devices (encoders, limit switches, etc.) While Cyborg can define a simple motor controller device which can be used directly by custom controllers, it is often better to organize motor controllers and feedback devices into structures that parallel the underlying robot structure. There are a number of classes designed to do exactly that. Looking at the hierarchy for a differential drivetrain we would have:

CBDifferentialDriveController

• CBDriveModule
• • CBSpeedControllerArrayController
• • • CBEncoder
• • • CBSpeedController

CBSpeedController

From the bottom up we start with simple speed controllers (CBSpeedController). There are a variety of speed controller classes that can provide specialized functionality based on the type of controller. These individual classes wrap whatever functionality is required to communicate with the specific type of controller is being used.

CBSpeedControllerArrayController

In a drivetrain, there are often multiple motors working together as a unit, typically connected to a single gearbox. In this case the where multiple speed controllers are "ganged" to produce a single output which needs a single feedback device, we can organize them into a CBSpeedControllerArrayController. There are several classes which implement this functionality. Ironically it is the feedback device that determines the structure here, not the motors. If two motors were not physically connected and used two independent encoders, then the they would best be broken into two CBSpeedControllerArrayControllers even though each "array" would consist of a single motor. Each controller array controls a block of speed controllers and motors as if they are a single unit providing the same control signals to each motor. Controller arrays are useful in many applications unrelated to drivetrains are the standard high level motor control classes.

CBDriveModule

To give a drivetrain "shape" we need to know more than just what arrays of motors are connected, we need to know the geometry. This is handled by creating a CBDriveModule which groups an array of controller arrays with an effective geometry component. This geometry is based on the effective "result" of the group of motors, gearboxes, wheels, etc. So for a differential drive with three wheels on each side, the effective geometry is typically offset of the location of the center wheel from the center of the robot. There are other factors as well including a force vector which describes the effect on the robot when the motors turn.

CBDifferentialDriveController

Based on its type some collection of drive modules make up a drivetrain. There are two general types of drivetrains - those that are "locked" to the floor (i.e. tank) and those that move based on a force balance (i.e. mecanum). Typically drive module controls can be calculated independently, but in the case of force balance drive trains, each module's operation is dependent on the geometry of all of the modules. When the drivetrain is given a high level motion request it calculates what each module should do and the control signals are passed down the hierarchy to the the individual speed controllers. As such in general there is no reason for any of the robot behaviors to even know of the existence of those speed controllers and there should be no "contact" with those devices by any other part of the system.