Authors – Ritik Mishra, Grant Silewski

Introduction

We got a lot of work done on both robots this weekend! We added limit switches to our practice robot, hooked up some more encoders, and fixed small issues all around that needed to be addressed. We also made considerable progress on our competition robot, and there is still plenty more to do with that!

Ideas for weight savings

 

What still needs to get done on the practice robot is to finish up adding sensors to the active/elevator, and finish putting on the butterfly.

Students working on the final robot drive train

 

What still needs to get done on the competition robot is grinding the elevator so it fits, adding the butterfly, pulleys on the bottom of the elevator with the polycarbonate guide, weight saving techniques, carriage brake, mounting the climber gearbox, and all of the electronics/energy chain.

Pulleys under the Elevator

Carriage Brake

After some development, we found a way to brake our carriage into our second stage for when we climbing. It pretty much just uses the active intake cylinders, as they essentially have three positions. We have yet to test this, but through moving it with our hands, it seems to be a lightweight solution for a necessary subsystem.

Active Intake

We tested our active intake and it seemed to work surprisingly well in all orientations. We had to replace the belt on the rotation to just #25 chain, as it was slipping too much, and we switched out the cylinders on the active to two position instead of single actuated. We also added hard stops and limit switches for safety and ease of use.

Ritik and Poorva working on the active

Subsystem Discussions

The robot is currently having issues with different commands interrupting each other. This is a side effect of the way that WPILib structures Subsystems and Commands. In WPILIB, a Subsystem is a group of motors, pneumatics, and other contraptions, while a Command is an action that can require 0 or more Subsystems. If a Command requires a Subsystem, it halts all other Commands that also require that Subsystem. This is a good idea for robot safety, but requiring Subsystems can have unintended effects on the robot.

 

For example, the Command that toggles whether the active is grabbing a block or not requires the Active Intake Subsystem. So does the Command that spins the active in, allowing it to eat cubes. As a result, if Driver 2 grabs the block while spinning in the active, WPILib will halt the spinning-in Command for the 20 ms that the grabbing Command runs (WPILib operates on a 20 ms loop).

However, the grabbing Command should ideally require the Active Intake Subsystem. Not doing checks that prevent unintended behavior can result in — you guessed it — unintended behavior.

 

The programmers have come up with several ways to deal with it

 

• Don’t require subsystems when necessary
  • This idea has been largely scrapped for the reason mentioned above
• Put all the solenoids in one big subsystem
  • This makes no sense from a build standpoint, as solenoids from unrelated parts of the robot will be grouped together.
  • Additionally, this will prevent multiple solenoids from being activated simultaneously (e.g climber and butterfly)
• Put all the solenoids in their own subsystems
  • This has the side effect of creating lots of extra files and making the codebase less maintainable
• Nucleate the subsystems
  • This involves creating Subsystems inside Subsystems. This is quite similar to the idea above, but will also occur for motors as well. However, this will drastically increase the size of the codebase and also risks decreasing maintainability.

 

Power Chain

Today, the power chain on the practice robot was reworked for the “second to last time,” as a mentor put it. Rather than curving at the top and being straight at the bottom, the power chain has been turned sideways and curves at the bottom, making the front of the robot look like the letter J. As a result, someone suggested that we name the robot Jerome (since J is for Jerome), but another stated that Jerome was a ‘dumb name’. A third onlooker foolishly pointed out that the front of the robot looked like an H, so it should be named Hershel.

Safety

 

Quote of the Day

“Robots should not quit, but yours did” — WPILib insulting Hershel