Day 7: Shooter and Prototypes

Prototyping

Double Wheel Flywheel

Today, we added wooden bars to prevent the ball from moving back and forth, as well as moving the polycord to the outside to limit disturbance. We then tested it, and it was very consistent and accurate. After fine tuning for a time, we realized only one flywheel was getting powered in testing. We then connected the other flywheel and retested it. The shooter’s speed and accuracy was improved greatly with the change.

Testing:

Single Wheel Flywheel

Today we worked on a single wheel flywheel, independent of Dropshot. We began by cutting a design built to be extremely modular. After assembling the design with a 3:1 gearbox and powering directly from a battery, we found it to shoot far too fast. We changed the gear ratio to a 5:1 to account for this, and it improved drastically. In the next step, we changed back to a 3:1 gearbox, and attached the prototype to a Roborio and speed controllers. The prototype had too much spin, and did not grab the hood. We added polyurethane strips onto the hood, and this improved the compression and grip. The 4" fairlane wheels we were using started to come apart, so we replaced them with the wheels we used on Dropshot last year. We tested those, but found there to be too much compression. Next build we will most likely continue iterate to iterate this design to find the most effective qualities and use those.

Testing:

Retrofitted Dropshot Shooter

During this build, we found that the retrofitting Dropshot with a shooter proved useless (the other single wheel flywheel proved much more viable) and unrepeatable, so we abandoned this effort.

Intake

Today we did our first testing session of the intake/hopper combo on the 2013 drivebase. After a few simple iterations (small geometry changes, etc.) we were able to intake balls pretty effectively, although not as fast as we would have liked. When we drove the robot at full speed into a dense cluster of balls, we knocked away a considerable amount of the balls because the intake couldn't keep up with the speed of the drivebase. We were unable to effectively speed up the intake by using less of a gear reduction, because the intake would brown out and trip its breaker when the hopper was filling up. To solve this issue, we plan to add a second motor to the intake and further decrease the reduction (to 3:1) in order to intake fast enough. If all goes well, we should have an intake that meets all our goals by Friday. As a refresher, the goals for the intake are to be able to drive full speed into a cluster of balls, and have any ball that touches the front of the robot be sucked in. It also needs to stay compact in terms of depth, so that we can maximize the hopper space with the limited volume we have.

Testing:

Programming

Camera Calibration

While working outside of the lab, some programmers achieved initial success with the camera calibration code and were able to view calibration frames from a webcam, but were unable to link that to the PIXY camera yet. The software to communicate with the camera has been developed separately, and will need to be linked in, and then finally some performance issues will need to be addressed.

Camera Communication

Today we continued work on interfacing the PixyCam with the Roborio over SPI. Now that we're reading actual data from the Pixy, the challenge was to start making sense of that data. For each frame, the Pixy sends a list of the bounding boxes of detected objects ("blocks"). The information for each block is in a regular, consistent format. However, after debugging the raw data from the Pixy, we found that blocks (and frames) seem to begin at arbitrary places in the stream of bytes, with zeros (00) filling the gaps between them. We've modified and build some new functionality behind the scenes to allow code to handle this; a little more debugging and the robot should be getting a consistent flow of vision information.