SystemCore / MotionCore Hardware Testing Progress Updates

We are testing a small mecanum drivetrain using a SystemCore, MotionCore, four REV A301 motors, an Xbox controller, and the built-in SystemCore IMU.

The drivetrain uses 100 mm wheels. The wheelbase is approximately 300 mm, and the distance between the left and right bearings is approximately 288.5 mm. The A301 motors are rated for approximately 500 RPM.

Initial Software Setup

The project was created using WPILib 2027 alpha 6. Several standard WPILib APIs are different in this version.

The project initially used a normal robotInit() method, which caused the following error:

The method robotInit() of type Robot must override or implement a supertype method
The 2027 alpha version no longer uses the traditional robotInit() method. Robot initialization was moved into the Robot() constructor.

The project also initially attempted to use:
autonomousCommand.schedule();

This caused:
The method schedule() is undefined for the type Command

The command framework uses the command scheduler directly:
CommandScheduler.getInstance().schedule(autonomousCommand);

SystemCore and MotionCore Setup

The robot code was deployed to the SystemCore using the WPILib 2027 alpha toolchain.
The A301 motors are connected to the MotionCore CAN-D ports. The port assignments were moved into:
src/main/java/frc/robot/HardwareConstants.java

The current port configuration is:

public static final int BACK_LEFT_CAN_PORT = CANBusMap.CAN_D0;
public static final int FRONT_LEFT_CAN_PORT = CANBusMap.CAN_D1;
public static final int FRONT_RIGHT_CAN_PORT = CANBusMap.CAN_D2;
public static final int BACK_RIGHT_CAN_PORT = CANBusMap.CAN_D3;

The Xbox controller port is also configured in the same file:
public static final int DRIVER_CONTROLLER_PORT = 0;

This allows the hardware ports to be changed without modifying the main drivetrain code.

CAN Port Type Problem

A type mismatch occurred when the CAN-D constants were declared as CANBusMap objects.
The error happened because CANBusMap.CAN_D0 through CAN_D3 are integer port values. The declarations were changed to int, which matches the A301 constructor.
The A301 motors are now created using the configurable hardware constants:

private final A301 backLeft = new A301(HardwareConstants.BACK_LEFT_CAN_PORT);
private final A301 frontLeft = new A301(HardwareConstants.FRONT_LEFT_CAN_PORT);
private final A301 frontRight = new A301(HardwareConstants.FRONT_RIGHT_CAN_PORT);
private final A301 backRight = new A301(HardwareConstants.BACK_RIGHT_CAN_PORT);

A301 Motor Control

The original motor code used velocity control:
motor.setVelocity(...)

During early testing, the motors did not respond reliably using this method.
The drivetrain was changed to direct throttle control:
motor.setThrottle(...)

The direct throttle method successfully moved the robot during hardware testing.
The integrated A301 encoders are still being read for feedback, and the SystemCore IMU is used for heading information.

The current maximum wheel speed is set conservatively:
public static final double MAX_WHEEL_RPM = 350.0;

This can be increased toward the A301 rated speed of 500 RPM after the drivetrain is operating consistently.

Motor Orientation and Inversion

The front and rear motors are physically mounted in different orientations because of the through-bore motor installation.
The current inversion configuration is:

frontLeft.setInverted(true);
frontRight.setInverted(true);
backLeft.setInverted(false);
backRight.setInverted(false);

This configuration allows the robot to move forward. Further testing is still needed to confirm the correct inversion behavior during strafing and rotation.

Hardware Autonomous Test

A direct hardware autonomous test was added to verify the motor outputs without depending on external trajectory software.
The test commands the drivetrain to move forward at a fixed speed for approximately two seconds and then stops the motors.
The test uses:
new ChassisVelocities(TEST_AUTO_SPEED_MPS, 0.0, 0.0)

The current test speed is:
private static final double TEST_AUTO_SPEED_MPS = 0.65;
The test duration is approximately two seconds:
private static final int TEST_AUTO_CYCLES = 100;
The test is selected in Elastic as:

hardware test (direct forward)

This test successfully moved the robot. This confirmed that the SystemCore, MotionCore, A301 output commands, CAN connections, and basic drivetrain output were functioning.

Motor Stuttering

The motors stuttered during movement, especially when strafing left and right.
Possible causes included:

1. Low throttle values not overcoming static friction.
2. Joystick axis noise.
3. Sudden changes in throttle commands.
4. Different mounting orientations between the front and rear motors.
5. Open-loop throttle control.
6. Encoder feedback signs not matching motor output signs.
7. Mecanum strafing requiring opposite wheel directions at the same time.

An initial minimum-throttle solution was tested, but it caused sudden jumps to a fixed output level. This was removed.
A low-pass throttle filter was added instead:
public static final double THROTTLE_FILTER_ALPHA = 0.25;
The filter gradually changes the throttle command and prevents abrupt changes between control loops.
A separate deadband was also added for the lateral joystick axis:
public static final double STRAFE_DEADBAND = 0.14;
This prevents small joystick movements and controller noise from repeatedly changing the direction of the strafing motors.

Xbox Controller Testing

The Xbox controller controls the mecanum drivetrain using:

Left stick Y: forward and reverse.
Left stick X: left and right strafing.
Right stick X: rotation.

The joystick values are processed with a deadband and squared response curve to make low-speed control easier.
The controller port is configured in:
src/main/java/frc/robot/HardwareConstants.java

Field-Oriented Driving

Field-oriented driving was added using the built-in SystemCore IMU.
The controls are:

Hold Xbox Right Bumper: field-oriented driving.
Release Xbox Right Bumper: robot-oriented driving.
Press Xbox Start: reset the current robot direction as field-forward.

The field-oriented state is published to Elastic as:

Drive/FieldOriented

The robot heading is read from the built-in IMU and used to convert field-relative joystick commands into robot-relative drivetrain commands.

The project should be compiled and deployed from the WPILib 2027 alpha VS Code environment, which includes the required Java runtime and SystemCore toolchain.

Problems with Ports on Motioncore

We connected 4 A301 motors to ports D0-D3 as mentioned above. However after a battery change one of the motors stopped working. We first thought the motor was the problem, but the motor was still visible in the Rev Hardware Client. Also the motor was blinking blue. After that we tested the port, we connected the troubled cable to a different port and it worked but now another port stopped working. We first thought it was about the software (which never happened before) and when we tested the motors individually in Rev Hardware Client the same ones were not working. Then we moved the entire cables to ports D2-D5. The motors worked with no problem. We coped with this problem by changing ports and structuring the code so that ports are easily changeable.

Current Results

The following parts are working:

• SystemCore robot code deployment.
• MotionCore motor communication.
• Xbox controller input.
• Configurable controller port.
• Configurable MotionCore CAN-D ports.
• Four A301 motor objects.
• Direct A301 throttle output.
• Forward hardware autonomous testing.
• Built-in A301 encoder reading.
• Built-in SystemCore IMU heading.
• Basic mecanum forward and reverse movement.
• Field-oriented driving.
• Heading reset functionality.
• Elastic throttle telemetry.

The following parts still require additional testing:

• Final motor inversion settings.
• Smooth left and right strafing.
• Battery usage
• Encoder sign and odometry accuracy.
• Full-speed operation near 500 RPM.
• Long-term stability of direct throttle control.
• Whether the remaining stutter is caused by software, motor mounting, wheel friction, or electrical power delivery.