Previously, the programming team had supplied the engineering team with two test OpModes.  The first OpMode, called "VariableMotorTest" was a Teleop OpMode that allowed a driver to set various motor speeds.  This has been used by the team to help determine the right motor speeds to use for the intake motor and shooter motors. We also created another OpMode called ContinuousServoTest which spins the continuous servo.  This was used to help the engineers test the prototype "flappy servo" which is the mechanism used to transfer the disks from the intake to the shooter platform. At the Oct 19th meeting, the engineering team was able to mount the intake system onto the robot frame.  They were able to successfully test both the flappy servo and the intake motor, but not at the same time. At tonight's programmer meeting, we developed a new OpMode called Motor+ServoSpeedTest.  This OpMode combines the features of the other two OpModes by allowing a user to se...

This evening, the engineering team was able to successfully mount the intake system using the custom 3d-printed mounts. Once mounted, the team was able to use the test OpMode created by the programming team to run the intake. Running at full power, the intake brought the disks in way too fast and chaotically. The team ran several iterations and determined that a motor speed between 70% and 80% seemed to be the right one to start with. We also had to ensure that there was a cover over the transition from the intake to the flappy tubing or else the disks would fly over the tubes. We held a transparent sheet of plastic over the area and that drastically improved the performance.  

 Today, the engineers have started working on assembling and implementing our intake system. Our team members have designed and 3D printed many parts to use in our intake system. We still have much to do before our intake system is fully operational and some of us will CAD some more 3D parts between meetings. The programmers tweaked the vision software to fit the camera used. It worked "spectacularly" as noted by a programmer. A flowchart was drawn up for the driver control period.

 Today we completely planned out the intake system and should be ready to assemble it next meeting. We revisited the idea of a conveyor belt system but once again ultimately decided upon a series of wheels. We also brainstormed a customizable shooter mount with a protractor like design. Finally we sanity checked the flappy wheel with a variety of scenarios.

  Today, the team completed a series of smaller tasks. Caleb constructed the Flappy Wheel he designed with the help of Josh. Shelby constructed the chain drive for our intake. Josh, Caleb, and Shelby mocked up the design for the location and mounting of the intake motor.   And Nathan walked Charlie through programming the driver controls. \

  Tonight, we discussed the timeline leading up to the first League Meet, scheduled for the week of 16 November.  We currently have roughly 5 weeks to get everything ready for that meet.  The Mechanical/Engineering team has decided to opt out of building the claw mechanism to hold the wobble goal for the first meet.  Instead, they will focus on ensuring that we have strong intake, holding area, and shooting mechanisms. This will alter our original thoughts for Autonomous sequencing.  Originally, we discussed having the robot shoot the onboard discs before deploying the wobble goal.  However, if we have to push/pull the wobble goal, we should focus on moving it first rather than risk losing it while performing the shooting. Prior to the meeting, Nathan asked the development team to download and install Android Studio.  During the meeting, he gave a demonstration of the java code in Android Studio.  He used the RoadRunner code to point out some of t...

Today, the team worked on a prototype of the intake/collection system.  Elijah designed the flaps in OnShape and Caleb adjusted them to be longer.  The team used a drill to simulate the motor and ran several tests to see if the flaps were able to control the discs properly.   Here's Nathan and Brandon testing the updated Ring Shooter Prototype.  The motor speed has been set to 60% and the shooter itself is mounted on a stationary frame.

  The goal of this meeting was to build a test OpMode for the Mechanical/Engineering team to use with the prototype shooter.  They wanted to be able to change the motor speed in increments of +/- 5 so that they could perform various tests with the launcher. Nathan created a TeleOp OpMode and wrote the program while sharing his screen over the Discord video channel.  He used the opportunity to show Charlie how to map functions to the controller buttons and talked about some best practices like putting an empty "repeat while" loop after the button presses.  This eliminates the risk that the user holds the button down and the OpMode continuously changes the speed. In addition to using the bumpers for +5 or -5 motor speed, Nathan assigned discrete values of 0, 25, 50, 75, and 100 to various controller buttons.  That way, the testers won't need to press the button over-and-over to get to some of the more extreme values. Nathan also helped troubleshoot an issue relate...