Our manufacturing sub team has been blazing through the parts to make. They ended the day with 7 unique parts left to make. Two router parts, one mill part, and four lathe parts. Of the lathe parts two of them were missed on the initial release and just got Trello cards created at the end of the meeting. Another lathe part is stronger bumper pins which won’t hold up assembly or testing.

The intake assembly continued today, making good progress until we discovered the center to center distance doesn’t match any standard belt or pulley combinations. We managed to find a combination that is only slightly off and needs a custom 14T pulley 3D printed. This should work for testing and we’ve added a to do item to fix the center to center distance on the next intake iteration.

The arm assembly got the “choochoo” gear box assembled and mounted to the robot. This gear box iteration ditches the belt and adds a second reduction. There is one router part for the arm that is still in progress, this part is for the second joint of the arm. So we can still assemble the majority of the arm while the missing part gets finished on Saturday.

We figured out the issues we were having with our swerve drive. Below is what was happening when we tried to move in a circle and rotate at the same time. It was unable to be driven in field oriented mode.

The root cause of the issue was a mismatch between real life and what WPI lib expects. The Navx was reading the heading’s clockwise rotation as positive and ChassisSpeed fromFieldRelativeSpeeds expects the heading’s clockwise rotation as negative.

So how did this end up affecting us right now? We’ve been using the same release of code for the past two months and have been driving just fine. Why did it break?

The Navx has a re-calibration feature, this calibrates the gyro and it also has the ability to reorient axis’s to handle situations where you can’t mount your Navx parallel to the earth and facing upwards. By default the Navx’s heading rotation is clockwise positive. Our Navx is mounted upside down so this inverts it and clockwise is now negative matching what fromFieldRelativeSpeed expects.

While we were driving over the field the re-calibration button on the Navx must have gotten accidentally pressed. This re-calibrated the Navx to the upside down position and suddenly clockwise rotation is positive again. Re calibrating the Navx with the robot upside resolved the issue.

This seems slightly unlikely, but our second Navx we had on the robot is now missing the re-calibration and reset buttons they have been ripped off… The dangers of driving around with out your brain pan covered. Lesson learned, always wear your helmet.