FTC 8956 Progress Updates

[clarkrowley]

Day 1

Plan:

• Software Installs
• Firmware Update
• Bench test

[ThadHouse]

Just as a reminder, please make sure you're grabbing WPILib Alpha 6, Systemcore Beta Image 10, and the DS alpha 4.

[clarkrowley]

We pulled everything yesterday afternoon so yes, those are the versions we have running on the benchtop test now.

[clarkrowley]

Day 1: Single Expansion Hub Example

We installed the WPILib alpha, the hardware manager, and the driver station on a laptop and desktop. No issues with the software installations.

We wired the benchtop example with the provided power cable and some current team hardware and battery. We had no problem with the benchtop wiring.

We powered the SystemCore with the battery/expansion hub and a Rev USB-C cable (we tried without the external power, but figured out that external power was needed). The Hardware Manager found the SystemCore with no problems and we had the image ready to go. The Flash OS process took a while - we didn't time it, but one of the students estimates it could have been 10 minutes. It completed successfully.

We configured the SystemCore with the team number and updated the SSID and password we then connected over WiFi from the laptop and from the desktop running VSCode.

We created the ExpansionHub project in WPILib and built the project, and ran a deploy. The RIOLog window flashed something and went blank and reported no comms with the robot, but we checked that we still had comms and confirmed using the Driver Station that the system had comms and had the opmodes installed.

We ran the auto and teleop opmodes from the alpha DS using the standard Logitech Gamepad F310, and the motors and servos responded as expected.

[clarkrowley]

Day 1: Double Expansion Hub

We modified the code to allow for two expansion hubs. We then also performed tests using two expansion hubs, still with four motors. 3 motors are on Expansion Hub 0, and 1 motor is on Expansion Hub 1. Everything appears to be working fine with 2 Expansion hubs connected to the SystemCore.

We have yet to do any testing with encoders on the motors.

[clarkrowley]

Day 2

The stock hole pattern on the A310 body includes two threaded holes for the m4 on 16mm spacing for the goBILDA system so we started assembling a chassis based on goBILDA channel and wheels using the REV hub adapter.

We played with just adding the @Logged attribute in the Robot.java and the teleop opmode but that didn't do anything more than open a log file, so we added a NetworkTable in the opmode to track a couple of motor velocities using SmartDashboard.putNumber(). The Elastic Dashboard was able to display those while running, as was AdvantageScope once we scp'd the logfile from the systemcore and opened it.

We also tried setting motor3 in the ExpansionHub example to follow motor2 but that didn't seem to work. We'll try again next meeting:

  @Override
  public void start() {
    robot.motor3.follow(robot.motor2);    
  }

  @Override
  public void periodic() {
    robot.motor0.setThrottle(-userControls.getGamepad(0).getLeftY());
    robot.motor1.setThrottle(-userControls.getGamepad(0).getRightY());
    robot.motor2.setThrottle(-userControls.getGamepad(0).getLeftX());
    double m_vel_motor2 = robot.motor2.getEncoderVelocity();
    double m_vel_motor3 = robot.motor3.getEncoderVelocity();
    SmartDashboard.putNumber("motor 2 speed",m_vel_motor2);
    SmartDashboard.putNumber("motor 3 speed",m_vel_motor3);
  }

[ThadHouse]

In start, call robot.motor3.setEnabled(true). We'll make sure follow implicitly does this in future releases.

[Obstagoon2]

Hello, my name is Zakk, and I am one of the students participating in the 8956 alpha test. I have created a CAD model of our current testing chassis design, and I would like to share it with others.

It uses the GoBilda Strafer kit chassis as the frame, with 4 GoBilda Rhino wheels, each driven directly by the A301 motor.

As there is no current official CAD for the systemcore/motioncore, I have created my own. I hope to add the M18 battery holder in the near future.

This is the link to the CAD for anyone to take a look at it or copy it for personal use: https://cad.onshape.com/documents/67b6b87d1facc2cca88682cc/w/6a0c0887d514fac21aaf3f29/e/46cbdc4e4e021a2397c0e1dc?renderMode=0&uiState=6a0f65c5796f4f5631353c30

[clarkrowley]

We rewired our 2026 competition bot with a second expansion hub and systemcore instead of the control hub. We tested teleop code ported for the mecanum drive (Swyft motors) and intake (REV motor) and those worked as expected. We started to test shooter code but forgot that the motor follower requires both motors on the same hub so we need to rewire some more.

We also tried merging our old limelight 3A autoaim code with new code using LimelightHelpers.java modified for the new JSON library but that's going to take a lot of digging in.

We haven't started on whether the goBILDA pinpoint will be available over i2c through old or new hardware.

[clarkrowley]

We were able to confirm the PinPoint odometry module is working through I2C.

We were not able to get the LimeLight3A to work using LimeLightHelpers.java to retrieve data from NT - the full NetworkTables did not seem to be populated. Tried port forwarding to get to the configuration screens but may have been talking to the wrong hardware.

We just reproduced FTC 21430 "BroomBots" report - we've updated the A301 firmware on a new chassis setup with 4 motors, confirmed using the REV hardware client that the motors turn under power, confirmed through the MotionCore web interface that the four a301s are reporting their status and absolute encoder positions under the correct CAN Bus IDs, and found that a call to motor.setThrottle() has no effect and a read of the encoder velocity using getEncoderVelocity().get() reports 0 if we rotate the motor by hand. We tried both a301(BusId) with all devIDs=3 and a301(BusId, DevID) with different CAN IDs.

[jfabellera]

Can you post the relevant code snippets where you create the A301 objects and throttle command?

[gearsincorg]

BroomBots were using the wrong CAN IDs for the two motors.

Ports 0 and 1 are actually on the Systemcore. For the motion core, you want to use these constants:

CANBusMap.CAN_D0
CANBusMap.CAN_D1

Which actually translate to 5 and 6.
0-4 are on the SystemCore.

[clarkrowley]

Thanks! So if we have 4 motors (and leave the default devID=3) in D0, D1, D13, D14 these would be equivalent? Our next meeting is tomorrow so we will confirm then -

public final A301 left_front = new A301(CANBusMap.CAN_D0);
public final A301 left_back = new A301(CANBusMap.CAN_D1);
public final A301 right_front = new A301(CANBusMap.CAN_D13);
public final A301 right_back = new A301(CANBusMap.CAN_D14);

public final A301 left_front = new A301(5);
public final A301 left_back = new A301(6);
public final A301 right_front = new A301(18);
public final A301 right_back = new A301(19);

[ThadHouse]

Correct. Thats why the CAN map definitions exist, because its a bit confusing.

https://github.com/wpilibsuite/allwpilib/blob/main/hal/src/main/java/org/wpilib/hardware/hal/CANBusMap.java

The defs are here BTW.

[clarkrowley]

Any value in adding a sentence about the CANBusMap to A301.md where it's referenced in the first constructor? or maybe not if the updated docs for the A301 alpha testing are coming anyway.

[Kevin-OConnor]

Sure! Just added a note below the constructor snippet and also made #286 to remind us that this API needs iteration to remove this easy source of error.

[clarkrowley]

With the updated CAN Bus IDs, we were able to test drive our mecanum chassis using 4 A301s with the 500RPM gearboxes. We ran it out for a few minutes just to see the motor temperatures rise and they went up to 39-40C but not higher with the lightweight chassis. We did a quick test using two 500RPMs to make a crude winch to lift the robot and the results were consistent with the expected stall torque for that gearbox. We plan to try designing an intake for the next year game pieces to add to the chassis.