FTC #25564 Progress Updates #372
Mretmna
started this conversation in
FTC Progress Updates
Replies: 3 comments 1 reply
Autonomous TestHere is the match test with the new motors. autontest_ftc2.mov |
0 replies
Drive TestHere is a clip from the testing process of the drivtrain. initialtests_ftc.MP4 |
0 replies
|
Thanks for the report @Mretmna - which version of the OS were you running when you experienced issues with Motioncore Ports / A301 enablement? |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
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 project also initially attempted to use:
autonomousCommand.schedule();This caused:
The method schedule() is undefined for the type CommandThe 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.javaThe current port configuration is:
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:
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:
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:
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:
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:
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.javaField-Oriented Driving
Field-oriented driving was added using the built-in SystemCore IMU.
The controls are:
The field-oriented state is published to Elastic as:
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:
The following parts still require additional testing:
All reactions