Eagan Robotics (26869, 26870, 26871, 26872) Progress Updates

[cadandcookies]

Hi all!

We were really excited to start working so we got started with things as they currently are.

Task 1:

• Wire robot for Systemcore with Expansion Hub(s)
• Install WPILib Alpha 5
• Update Systemcore Beta OS to limelightosr-beta-10-138
• Installed the new driver station
• Ran example program

Feedback:

• Wiring was fairly straightforward, though if we realized we needed the old Mini-B cables for this we wouldn't have gotten rid of them! If we run this configuration in-season we'll need to pick up some of the REV port saver packs.
• Software installation/updates proceeded without a hitch
• Example program is currently broken as noted in another discussion thread. It took a bit of looking at things and then seeing a discussion on here to realize this. No harm no foul though, I don't think we actually got instructions to start yet.

We'll be repeating some of this setup as students become available (most are currently busy with standardized tests).

Here's our test chassis:

[cadandcookies]

Task 2:
We did start writing some very basic robot code just to make sure we can get a normal FTC mecanum drive running decently.

We were pleasantly surprised by how easy this was to extend from just the Mecanum example. The Systemcore built in IMU orientations were also a little confusing at first, but overall it was pretty straightforward.

Below is the entirety of our robot code for that-- not too bad!

package first.robot;

import org.wpilib.drive.MecanumDrive;
import org.wpilib.driverstation.DefaultUserControls;
import org.wpilib.framework.TimedRobot;
import org.wpilib.hardware.expansionhub.ExpansionHubMotor;
import org.wpilib.hardware.imu.OnboardIMU;

public class Robot extends TimedRobot {
  public final ExpansionHubMotor rearRight = new ExpansionHubMotor(0, 0);
  public final ExpansionHubMotor rearLeft = new ExpansionHubMotor(0, 1);
  public final ExpansionHubMotor frontRight = new ExpansionHubMotor(0, 2);
  public final ExpansionHubMotor frontLeft = new ExpansionHubMotor(0, 3);
  private static final OnboardIMU.MountOrientation kIMUMountOrientation =
      OnboardIMU.MountOrientation.LANDSCAPE;

  private final MecanumDrive robotDrive;
  private final OnboardIMU imu = new OnboardIMU(kIMUMountOrientation);
  private final DefaultUserControls controls = new DefaultUserControls();

  public Robot() {
    frontLeft.setReversed(true);
    rearLeft.setReversed(true);

    imu.resetYaw();

    robotDrive =
        new MecanumDrive(
            frontLeft::setThrottle,
            rearLeft::setThrottle,
            frontRight::setThrottle,
            rearRight::setThrottle);
  }

  @Override
  public void teleopPeriodic() {
    robotDrive.driveCartesian(
        -controls.getGamepad(0).getLeftY(), 
        controls.getGamepad(0).getLeftX(), 
        controls.getGamepad(0).getRightX(), 
        imu.getRotation2d());
  }
}

Additional things we plan to explore in the near future:

• Integrating FRC-style dashboards and logging
• Using our Pinpoint odometry modules
• Autonomous modes using the above

[cadandcookies]

A301 Hardware Update:

It's been a minute since we posted an update, but I figure we can post a bit of team member observations about the new A301 hardware we received on Thursday. We hope that some of these pictures and impressions are useful to the folks at FIRST + Limelight and anyone in the community following along.

For the below, these pictures are taken on a cutting mat with a 10mm grid.

A301s:

These are extremely solid feeling pieces of hardware. The aluminum feels nice, and the updated hole patterns (more M3 holes, and two additional M4 holes that line up with GoBilda pattern) are much appreciated.

Assembling the A301 with a gearbox felt pretty solid and easy, though it feels like it might be possible to damage something if someone were to force the gearbox on with the gear teeth not in alignment. It also felt like it might be possible to damage the gearbox by over-tightening the screws that attach it to the A301 body. We also weren't sure what plastic the casing was made of and whether loctite was safe with it.

The gearbox cartridges feel solid enough. The small spline shaft on them looked concerning, but feels pretty solid in hand, and the teeth on the gears are substantial.

The fit on things generally is very nice.

Battery Mount/Switch:

The battery mount/switch seems to be a prototype. It is pretty nice for that, but also has some misses that if this is a prototype for a real product would hopefully be addressed.

One of the more surprising (though perhaps not in hindsight) things about this is the sheer size of it. It is HUGE compared to the current battery+switch, and weighs a bit more too. This means we'd probably be trying to put it low on a robot for center of gravity reasons, and also means that the switch placement is less than ideal for compact robots.

Conveniently the hole pattern is an 8mm grid, with some 4mm holes, but the material on the side that doesn't have a line of holes seems pretty sketch as far as drilling them out to M4. I'd hope with an actual product there would be enough material to do that.

Photos

I'm attaching images for folks at home to understand what we got. Super excited to dig into testing with the A301! We plan to keep the chassis pictured above together and move the Systemcore back and forth between that and an A301 test bed.

[Kevin-OConnor]

It's a terminator switch for the CAN bus. It should only be needed for using the A301 on an FRC CAN bus if you don't want termination enabled.

[CoachBill]

Do you have a photo of the converted robot?

[qwertychouskie]

Does the A301 have M4 holes on both sides, or just the one side? Either way, great to see M4 integrated, that was one of my primary concerns with the A301 as originally shown off in the initial announcement.

Also, I wonder how the size of the prototype dock compares to the https://www.gobilda.com/gobilda-smart-dock-for-20v-battery-dewalt-20v-max-compatible/

[qwertychouskie]

Also, does the prototype dock feature under-voltage cutoff, and over-current/over-temperature protection?

[cadandcookies]

Responses to the above:

• @CoachBill We haven't converted a Strafer to A301 yet, that will probably happen next week. The hybrid robot is pictured in the first post.
• @qwertychouskie There are only M4 holes on the gearbox side of the motor. Comparing the size to the Gobilda Dewalt product linked, the prototype Milwaukee dock is ~80mm wide x 127mm long x 40mm tall. I know nothing of future plans for Milwaukee-based battery systems, but the unit we got is a 3D printed casing with what looks like an off the shelf official Milwaukee adapter/port thing. There is pretty clearly plenty of room on the table for a more compact unit as a product and I wouldn't assume this is the final form factor.
• Not sure about cutoffs/overcurrent/etc, we haven't tested that.

[cadandcookies]

Got the A301s running on the table today and took a look at just a quick "run these in a sine wave" auto, and saw some data that I'm hoping one of the REV folks can explain:

The above graph running 7 A301 motors in a sinusoidal pattern (0 to 1 to 0 to -1 to 0), graphing the current draw (in amps, I believe?) from the getOutputCurrent method. It appears to show a peak output current of close to 15 amps for a single A301 motor. This seems... really high? Are our units defective? Is this expected? Has anyone else done a similar test? Are we missing something?

Also interesting is that it seems that the motors are drawing less current running in reverse. This is no-load, just running on the benchtop.

In any case, looking forward to continuing testing!

[cadandcookies]

Also at the request of someone on discord, reran this with the getAppliedOutput logged as well:
WPILIB_TBD_0a9f4d030d08de97.wpilog.zip

[revspin]

@cadandcookies , thanks for the data. I don't think your units are defective; this is expected behavior based on the control mode and the metric being measured.

Control Mode: Duty cycle control is a voltage control mode, meaning current is not tightly regulated other than via safety clamping. If you need tight current control, please use the Current, Velocity, or Position closed-loop setpoints.

Phase Current vs. DC Current: The getOutputCurrent method currently reports motor phase current, which can be significantly higher than the DC input current from your power supply due to the controller's switching mechanics.

[cadandcookies]

That makes sense. I ran the above sinusoidal target test with velocity mode and it tracks pretty well, even for the motors that weren't quite hitting the expected max in throttle mode.

Logs/graph for anyone following along at home:
WPILIB_TBD_51342b08190962c7.wpilog.zip

[qwertychouskie]

It looks like AppliedOutput is constantly spiking into the negative in throttle mode. That definitely feels like a bug to me; at a minimum, that seems terrible for efficiency.

In throttle mode, it also looks like there's a ton of motor-to-motor variance, and also a huge difference in one direction vs the other. "100% throttle" often falling way short of the speed that velocity control is able to hit feels very wrong; by definition, that's not 100% throttle.

I'm aware that "throttle" is probably difficult to imement in a way that feels correct when doing voltage compensation, but the current implementation seems to be quite flawed at the moment, at least compared to how I would expect a "throttle" setting to work.

[Dubble-Bubble]

I am surprised that a NEGATIVE output application during positive throttle application in code is happening. I wonder if there is a firmware cause? It certainly isn't just applying duty cycle, and voltage compensation typically doesn't cause sign flips.
The forward vs backwards discrepancy is also interesting, though it doesn't persist in vel mode.