Blog

FRC Day 7 Build Blog

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.

Inline image 2

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.

Inline image 3

Inline image 4

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.

Inline image 5

Inline image 7

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.

FRC Day 6 Build Blog

Day 6: Shooter Prototyping

Prototyping

Double Wheel Vertical Flywheel

The design of this shooter is based around two rollers feeding into two wheels that spin rapidly, compressing and shooting the ball into the goal. When we tested this prototype, we found it shot very wildly. We figured we needed another wheel above the first two to act as an active hood in order to improve accuracy. We then cut into the plate to make room, and lasered new plates. This new design worked slightly better, but it needed more compression, so new plates were lasered and assembled; however, we ran out of time to test it and will test it next time we meet.

Testing:

Double Belt Shooter

Today, we worked on prototyping a polybelt shoot using a design which was designed outside of lab hours. We began by modifying the design to work alongside the polybelt, as the original design assumed that the center to center distance between shafts could change. After changing the design and cutting new plates, we assembled the shooter. We used a 775 Pro motor with a VersaPlanetery gearbox with a 5:1 reduction. After testing it and finding that the roller speed was too slow, we replaced the 5:1 with a 3:1 and found an immediate improvement. We also increased the compression on the balls on our feeding mechanism by adding polyurethane strips to our feeder plate. While our shooter was able to shoot balls, accuracy was low and there was a significant amount of variability between shots. We were not confident about what the issue was, but we now are sure that we need to provide more energy to the balls and in a more efficient manner.

Testing:

Retrofitted Dropshot Shooter

Early in the season we modified dropshot to shoot the fuel balls. We are now working on a new version that will have a powered feeder and new rails to shoot the ball. We haven't finished assembly yet.

Programming

Robot Programming

We debugged some code that was written last build and got it to run on our prototype drive base and we also fixed an issue on our other development board by replacing the radio. Also, the web configuration code that we used in 2015 was ported to this year’s code base for easy constants configuration. With all of the prototypes we were working on, the github started getting messy, so we cleaned it up by branching and adding more files to the gitignore.

Camera Calibration

Today we worked a lot on Camera Calibration. In the morning, we got some code that allows OpenCV (the library we use for calibration) to directly communicate with the Pixy Cam. Other than some small fuzziness at the bottom of the image, it seems to be working well. In the afternoon, we merged that code with the calibration code. Also, we mounted the dot grid that is used to calibrate the camera, on a piece of wood, so it is flat and can consistently calibrate all of the cameras.

Vision Targets

Today we started to build a 1/5 scale model of the high goal of the boiler. What we did was laser cut a CAD of a circle, twice. What we need to do next meeting, is put up the support beam in the middle, and wrap the whole thing in paper and reflective tape. This should be an accurate representation of the boiler that we can use.

FRC Day 5 Build Blog

Day 5: Strides in Prototyping and Testing


Prototyping


Shooter

Today we worked on assembling and improving the shooter. After assembling a plethora of VersaPlanetary gearboxes, forming polycord, and machining new hubs for the flywheel, we managed to assemble the prototype. After testing it, we found the real world version to have varied from the CAD, and the compression on the flywheel to be too much. We recut the two shooter side plates to allow for more reasonable levels of compression. We then hooked the prototype up to a mock drivebase and speed controllers. When we tested it, we found that the shooting was inconsistent, most likely due to dead space between the feeder and the flywheels. We tried killing one side of the feeder and changing to a fixed plywood side to lower the variability. While the variability was removed, the spin increased so this plan was immediately scrapped. We then tried to add a makeshift barrel, around 6 inches in diameter and in length. This barrel significantly increased our shooting accuracy. Later, we will have to choose whether or not to have a wide shooter or multiple separate flywheels.

Fuel Intake and Hopper

Today we made great progress on the intake and the hopper. We assembled the updated design from yesterday, and it while it was better (faster, more balls made it over the bumper), we still had the issue of some balls becoming stuck in a "dead zone" and not fully clearing the bumper. To fix this, we decided to try putting 8 thick zip ties on the top roller with about two inches of uncut length, in order to kick the balls up and over the bumper when they got stuck. The results were fantastic: the intake overall worked much faster and balls never got stuck anymore. It seems like this is close to the design that will be implemented in the real robot later on.

After thoroughly testing the intake, we began work on a prototype hopper that would sit directly behind the intake and hold about 150 balls. This prototype has a sloped floor, which will help funnel balls to the back of the robot so we can continue to intake efficiently and feed into the back conveyor belt that will lead to the shooter. While the hopper was fully assembled and ready for testing, we did not get a chance to try it on the practice drivebase because it was being used for the shooter prototype. For the future, we will test the combination of the intake and hopper, and continue iterating those designs. We are also considering prototyping a hopper with a powered conveyor belt floor, to agitate the balls and feed them towards the back even faster.

Testing:

Gear Intake

Today’s build was essentially a continuation of what we did yesterday. We finished putting together the pieces that were CADed previously and fine-tuned the claw system so that it could consistently pick up gears and manipulate them in 360 degrees. One special feature of our design is that, even if one claw is out of position, the locking mechanism is still able to prevent the other individual claw arms from moving around. Although this design works extremely well as it is, the next step will be to condense it significantly so that it can meet the size constraints of the robot.

Drivebase

Today we nailed down an initial version of our drivebase which included the weldment, electronics baseplate, gearbox, and wheels. To finalize our design, changes may have to be made to the frame dimensions to accommodate both the ball and gear intake as well as the bumpers. Moving forward, our priorities are to pocket the baseplate and waterjet it out of 1/8" aluminum to save weight, design new mounting provisions/supports for the bumper rails for easy access, and potentially modify the main breaker placement which is currently positioned in the bumper rail.

Climber

After mounting the “comb” onto a shaft, we were ready to begin putting together the climbing prototype. However, we soon ran into some problems with the VersaPlanetary gearbox we constructed. After taking it apart and putting it back together (with a 10:1 gear ratio), we were ready to restart testing. At this point we ran into another problem as our setup proved to be unstable, making it impossible for the prototype to run smoothly.. We lasercut new, larger sidepanels and attached them to a 2×4 for stability. Next, we recut the metal bar we had used to stop it from interfering from the turning of the comb. Finally, we were ready to attach it to Dropshot’s drivebase, set up a hanging station, and start testing. While the prototype could successfully grab and hold onto the rope, it just did not have enough power to life the entire robot (even after changing to a 50:1 gear ratio in the VersaPlanetary). Looking toward the next build, we’ll have to find a way to increase the prototypes strength and speed.

Full Robot Mockup

The team created a quick mock up of the robot that features an intake on the front and shooter in the back. A large hopper made of polycarbonate pops out to over the bumpers to maximize its volume. A system of polycord or belts pulls the balls to the back of the robot then up into the shooter. It not a finalized design but serves as a start to get an idea of how much space subsystems like the bumpers and drivetrain take up so they can start being manufactured.

Programming

Robot Programming

Today, we fine-tuned a PID control loop for the intake. PID is a control algorithm that maintains a constant RPMs on a motor, regardless of motor loads. For example, a ball launcher’s motors may slow down when balls are inserted due to the increased load. PID would keep the motor’s RPM constant when a load like a ball is inserted.

We also rewired the encoders to connect to the RoboRIO instead of from the CAN Talon. At the moment, we are running our PID + feed forward loops off the RoboRIO (instead of the CAN Talon) and need the encoders to connect to the RoboRIO. While we can get encoder values from the CAN Talon, we need perfect time synchronization for the control loop on the RoboRIO, which we can accomplish by connecting the encoder to the RoboRIO.


Camera Connectivity

Today, we continued on the previous build’s progress, and decided to continue working on SPI. First, we connect the PixyCam to an Arduino and used the Arduino library to see if it worked correctly with the Arduino, as it hadn’t been working with the RoboRIO. Our test was successful, and the PixyCam worked as expected with the Arduino, leading us to conclude that there was a problem in the communication between the PixyCam and the RoboRIO. We connected the RoboRIO and Pixy pins to an oscilloscope to ensure that data was being transmitted correctly. After a few minutes of trying to get proper data, we realized that the PixyCam only broadcasted data when it saw an object; when no objects were detected, it would only send null bytes. This was the reason for the issues yesterday; when we got null bytes, we thought there was a communication error with the Pixy, as the documentation did not indicate that no data would be transferred when no objects were detected; we expected frame separators, but none were sent. After realizing this, we put a ball in front of the camera, which had been programmed to recognize balls, and updated our RoboRIO program to search for objects in a loop. At last, we were able to successfully retrieve object metadata, but we encountered connectivity issues between our driver station and the RoboRIO and were not able to finish our code. This build, we were able to get our program to parse the Pixy’s object broadcast data. Next build, we plan to finish our SPI driver by parsing the frame separator indicators, so we can recognize when there are multiple recognized objects in a single frame.

FRC Day 4 Build Blog

Day 4: Iteration of Prototypes

Prototyping

Double Wheel Vertical Flywheel

As we proved this flywheel could attain a high throughput, we transitioned today to begin testing different wheel types and compression as well as the conveyor system. In the process of setting up the next prototype, we found we lacked enough polycord pulleys, and machined more out of some delrin stock. We scavenged the 3:1 VersaPlanetary gearboxes from our previous prototype. While we did not have enough time to finish developing the prototype, we have all of the pieces and can finish it quickly tomorrow.

Fuel Intake

Taking the intake design from yesterday using two polyurethane rollers, we laser cut and assembled it, discovering that while it was able to pull balls up and over the bumper, the balls sometimes got stuck. the compression was too little on top of the bumper and it sometimes got stuck. The compression seemed to be too little at the top of the bumper because we didn't account for the bumper compressing alongside the ball, so we went back in CAD and redesigned the geometry of the upper roller to have increased compression. We are still in the assembly stage of the new and improved version, so we will see tomorrow how well it works with the improvements. For the future, we still have to see how effective the new design is before we CAD the real intake for the robot, but it is likely that this will be the preferred design because of the simplicity of having just 2 rollers.

Gear Intake

Throughout the course of the build today, we worked on constructing the 3D CAD design that one of the students made the day before. This worked out well because we were able to get the whole thing laser cut and fully constructed relatively quickly. Although this design seemed to be very similar to the previous version, a new key feature was added: A locking system for the claws while they are grabbing onto the gear. Although we were not able to fully test the design today, these improvements should theoretically allow us to manipulate the gear in 360 degrees, something we were not able to do previously. At the build tomorrow (Saturday), the main focus will be to finish building the prototype and look at potential ways of packaging the design give the tremendous size constraints presented.

Drivebase

Today we finalized the CAD Design for the Drive Gearbox, which is now almost ready for manufacturing. We started by pocketing the gearbox plates, a method used to reduce weight while maintaining the structural integrity of each plate. Our two gear ratios are 15:48 and 28:35. We decided to have a two stage gearbox with a dog shifter in anticipation of heavy defense, allowing the robot to have speed and maneuverability based on the situation. We also added spacers, an intermediate shaft, and designed a new front gearbox plate. Through the design of the gearbox plate, we were able to save 0.04 pounds in a game where the robot weight is inversely proportional to its speed.

Regarding the drivebase weldment, We modified it to have a cut out in the back. The gearboxes will sit in the two cutouts in the back corners and the gap in the middle will be for a gear intake mechanism..

Climber

Today, the rope-climbing project finished prototyping a “comb” to grab the rope as well as housing to connect the comb to the robot for testing. We completed the comb by measuring the diameter of the string to find the distance between each prong of the comb. After this, we cut these parts out and tested it by ensuring that rope with knots would successfully hook onto the comb. Besides this, we also created the housing by attaching a VersaPlanetary enabled motor to a wood structure. We then connected the motor to a shaft by using gears and bearings. At this point, we just need to attach the comb to the shaft in order to finish assembly and begin testing.

Programming

Camera Calibration:

After manually calibrating one camera with limited success, we decided to automate the process to make calibration quicker and more accurate. The goal of the project is to have the OpenCV calibration code to read the camera input automatically so that we can see what angles will work for calibration before we take the picture. Today we downloaded all the necessary software needed to run the calibration program (OpenCV, Eclipse C/C++, MinGW, etc.); however, we did not finish this. Needed for next build is to set up Eclipse with a compiler and Download all the premade libraries for OpenCV. After that, we can edit the code to make it more user friendly, by having it connect directly to the Pixy Camera, and improve calibration.

Camera Connectivity:

Today, we deployed multiple test programs to an old RoboRIO to test our serial driver. Unfortunately, we ran into many issues early on. We then created another program to dump raw SPI input data to attempt to diagnose the issue: we noticed that we were only receiving null bytes (0x00), perhaps due to an SPI protocol error. We found that this occurred because the SPI connection hardware had a loose contact issue between the RoboRIO’s pins and the header pinout; after this was fixed, we received (0xff) bytes. Unfortunately, even after attempting to replicate the protocol according to the description, we could not get the PixyCam to send us anything other than (0xff), which was oddly not documented in the protocol information page. However, we suspected that the issue may stem from WPILib’s abstraction of the SPI interface itself; thus, we plan to implement a PixyCam SPI driver in C/C++ based on a low level library that accesses the serial port directly. In addition to working on SPI, we also worked on our `libpixyusb` interface, attempting to run the sample program. Unfortunately, we received an error about a failure to transmit/receive data over USB; we traced down the issue in the libpixyusb source code to the low level USB handshake. Getting `libpixyusb` to work reliably on the RoboRIO will likely be extremely difficult, possibly even requiring custom drivers and a kernel patch; the exact same code works as expected on an Intel x86 laptop, but when cross-compiled onto a RoboRIO with the FRC C/C++ toolchain, it encounters this unexpected error. After evaluating the pros and cons of both methods of connectivity, we decided to continue to pursue SPI rather than USB.

Robot Programming

Last workday, we tried deploying robot code to the RoboRIO but ran into problems deploying the code due to conflicting libraries for the CAN Talon motor controllers. After removing the conflicting drivers, we were able to successfully deploy the robot code. These changes are reflected in the latest commit on Github.

We then successfully deployed the code for the shooter prototype to the RoboRIO, but faced problems with maintaining a constant RPM. We used a basic feed-forward controller, which should set a near-constant RPM, but we measured drastic fluctuations in the RPM. We hypothesize that this is because the encoder is returning data at a different rate than the robot is running, leading to discrepancies in the measured RPM. To fix this, we will try connecting the encoder directly to the RoboRIO’s digital inputs instead of to the CAN Talon.

Waypoint visualizer:

We worked on an autonomous mode path simulator. The app lets a user enter waypoints and speeds and plots out a path that the robot will take. The app also supports animating the robot's movement. We also worked on implementing a radius feature into the program that would allow the robot to round corners. This app is a vast improvement over the current method of programming paths which require trial and error. With a helpful web interface, we will be better equipped to plan auto routines before we even test them, which allows us to develop before the robot is built. It’s not done yet, but we have made a lot of progress:

FRC Day 3 Build Blog

Day 3: Progress in Prototypes

Prototyping

Double Wheel Vertical Flywheel

Today, we worked on assembling the Double Wheel Vertical Flywheel. Taking the parts from last build, we assembled it using the new VersaPlanetary gearboxes and encoders we received. We assembled the flywheel to our previous spec, but we had problems with the gears we had in stock. We changed the ratio in CAD and laser cut a new plate. After doing so, we assembled the flywheel. While the flywheel worked well after changing to polyurethane, the conveyor system failed. Rather than cutting a new plate, we cut a bearing hole and inserted a hex shaft on the inside of the polycord, essentially acting as a tensioner. This worked relatively well, but needs further refinement. We did prove our concept, and will further iterate to better understand how best to integrate our design with the robot.

Testing:

For the Double Wheel Variable Compression Vertical Flywheel, we assembled the majority of the pieces and only need to insert the wheels to begin testing.

Fuel Intake

We finished assembly and began testing the belt intake, which was very fast when pulling balls in, but protruded several inches beyond the bumper. We began to design a new intake today, which will be much more compact and will therefore allow for a larger hopper and more room for other systems. This intake uses no belts, and two polyurethane rollers pull the balls up and over the bumper into the hopper. This removes the inefficiency and added complexity of belts, and makes the whole design cleaner and simpler. The intake's design is finished in CAD, but it has not been built or tested yet. On Friday we will laser cut it, finish assembly, and test it to see how effective it it..

Testing:

Gear Intake

The Gear Intake development process continued today with the construction of a recently CADed design that has an inner slider in order to pinch the gear between the claws and itself. This process was difficult because the .25” plyowood that was used for construction is actually .2”, so the original design needed to be modified slightly so that all the pieces would fit together. Other small improvements involved adding polyurethane strips to the inner slider and the claw so that the whole system grips onto the gear well.

Testing:

Drivebase

We finished an initial weldment of the general structure modeled after our 2014 robot and the side rails/bearings/housings modeled after our 2016 robot. Taking bumpers and an intake into account, the frame was dimensioned to fit within the 36" by 40" by 24” size limit.

In addition, we designed the drive train gearbox in CAD with 2 CIM motors per side in a 2 stage reduction with a dog shifter and pancake piston to have 2 speeds: low gear for pushing force and high gear for maneuverability. With the design almost done, we only have to add spacers, intermediate shaft, standoffs, screws and nuts, retaining screws, and pocketing to the CAD (members can access the design from pdm under the name 254-17-A-0300 Gearbox if you want to see or help design it).

Climber

Today, we designed and began to build prototype mechanisms for climbing the rope. The prototypes for actually holding onto the rope included variations combs with differing spacing. We began working on a standard mount for each type of prototype climbing roller. We decided to use a VersaPlanetary gearbox in our build, using a gear ratio of 1:90 to heavily reduce the rpm of the motors from ~18,000 RPM and increase torque to ensure the robot could lift itself. We then assembled the multi-stage gearbox, attached the motor, and soldered the battery leads. Lastly, we began the process of building a frame and prepared the parts to completely assemble the mounts next build.

Programming

Control Board

On Wednesday, we met up and worked on control systems for recent prototypes and we also continued developing pixycam communication. We added three talons to the prototype board to support the growing complexity of prototypes.

Robot Programming

With a prototype board ready, we added feed-forward PID control to our two-roller shooter prototype. PID is a control loop that keeps a constant motor speed, allowing us to effectively test the shooter prototype.

We also rewrote a majority of our code using elements from last year’s code, to avoid re-inventing the wheel. The new code is far more scalable and efficient. In particular, we implemented Loopers, a structure that runs code extremely fast, and compartmentalized our code into the various (potential) subsystems on the robot. We also discussed code conventions to ensure uniformity in the code down the road.

However, we had issues with compiling and deploying the code due to issues with the motor controller driver. We’re resolving those issues down the road.

Camera Connectivity

We worked on camera connectivity, finishing a testable version of an SPI driver built on WPILib for the RoboRIO. Previously, we built a native library that allowed us to communicate with the PixyCam over USB and wrote a JNI wrapper to let us invoke the native code from Java, but today we encountered issues when connecting to a physical PixyCam. Rather than debugging the USB connection, we decided to ensure that we could build a reliable SPI driver first, as we are confident that we will be able to communicate with the camera over SPI. Though a USB interface would be optimal, it is significantly complex and we plan to work on that functionality once the SPI driver is confirmed to work as expected.. We added a new pinout to the PixyCam and connected it to an old RoboRIO board for testing. To help with testing, we connected the PixyCam to a computer and trained it to recognize the yellow game balls. In the upcoming builds, we will proceed with testing our SPI driver with an old RoboRIO so we have a working method of connection for this year’s code.

FRC Day 2 Build Blog

Day 2: Prototyping

Today, we continued our work on prototyping designs for the shooter, intake, and drivebase. Our programming team also worked through a variety of projects including camera calibration and configuring the RoboRIOS.

Shooters

Double Wheel Horizontal Flywheel

We assembled the feeder for the horizontal flywheel shooter using three wheels of two different sizes to optimize contact with fuel balls. We determined that we would either use polycord or rollers for the feeder. However, due to availability of resources, however, we decided to prototype with a wheel roller. The horizontal flywheel was ready for testing but is still waiting on more planetary gearboxes.

Double Wheel Vertical Flywheel

Today we continued working on developing a double wheel vertical flywheel. In the process, we tried to optimize throughput with the limited space available on the robot. Initially starting with a hand loaded prototype, we combined the shooter with a conveyor prototype to remove the variables of human error.. We managed to design and laser cut the sidepanels for the prototype, and began assembly. We have organized the VEX Pro VersaPlanetary gearboxes and will implement it on Wednesday.

Another project based off a double wheel vertical flywheel aimed to optimize the best materials and fuel compression to maximize accuracy and shot speed. We spent the build designing a model in Solidworks to later be laser cut.. By the end of build, we acquired all the materials for the prototype including the 80/20 Extrusion Material, T-nuts, modified Versa Side Bearing Motor Gussets, 2 x 4 Wood Blocks, Bearings, and laser cut to design ½” Plywood.

Catapult

We improved the catapult and eventually hit an accuracy rate of 15/15 into the high goal. The improvements we made include:

  • Adding a stronger shaft

  • Tightening the medical tubing that provided the power to pull the shaft to the hard stop

  • Moving the hard stop and axle into the optimal position

  • Figuring out how to calibrate the machine

  • Securing the catapult to a piece of plywood so it wouldn’t move after every shot.

The design still needs a lot of improvements based on the power applied and the contact with the ball to make it into the boiler quickly and consistently.

Testing:

Intake

Today we took the intake prototype from yesterday and added several more surgical tubing belts in order to pull in more balls at once. In addition, we resized it for better geometry and added a CIM motor for lots of power. The results are very successful, and we are able to rapidly suck in several balls at once over a bumper, meeting our original goal for this prototype. The next step is to mount it on our practice drivebase and see how well it can intake once in a robot. We prototyped this specific intake because we have used similar ones in the past successfully, but were unsure how they would react to the plastic balls compared to more traditional foam balls.

Testing:

Drivebase

Today for the 2015 Deadlift drivebase we installed a new radio with updated 2017 firmware in order to successfully connect to the driver station. Additionally we experimented with different types of wheels. Initially we started with colson wheels on the outside and an omni-wheel for turning. The idea was that due to the center drop of the drivebase we would only be on an omni, and a colson wheel at all times. In order to optimize for turning we changed to all omni wheels, yet the turning was erratic so we think another set of wheels would be best for this game.

Gear Intake

Today we worked on the gear intake for the 2017 FRC Robot. The process involved spending a little bit of time on CAD to create a preliminary design, and then following up by actually laser cutting the wood pieces and then putting them all together. After that, we experimented with different heights for the grabber pieces on the claw to figure out which angle would be optimal in sliding up and over the edge of the gear. The next step in this project will be to cad a significantly more robust version of a similar design, as well as add a system for actually “grabbing on” to the gear so that we can manipulate it.

Testing:

Programming

A lot got done in programming today! We had our first build meeting and we will be having subsequent meetings every build where we will get anyone involved who wants to work on something. During this build we divided the work into the following tasks:

  1. Installing updates onto drivers stations

  2. Camera USB to RoboRIO Communication

  3. Camera Calibration

  4. Programming prototype boards

Driver Stations

We successfully updated the driver station software on the driver station computers. Now, everything works well.

Camera USB to RoboRIO Communication

Since last build, we successfully cross-compiled libpixyusb to the RoboRIO’s ARM architecture using QEMU on Ubuntu. We then created a JNI for it so that we can integrate it into our codebase. However, it has not been tested yet and we will be doing this throughout the week. If his port works, then we will not be using SPI with the Pixy Camera

Camera Calibration

The goal of calibration is to get rid of the distortion in the camera. Here are some screenshots that illustrate this distortion:

After the calibration, the dots in the image or more linear and the edges of the dot grids are parallel. This is the result of the calibration:

With better calibration, we will be able to more accurately approximate the angles of the goals so that we can make the targets. The calibration above isn’t perfect, but we are still working on making it better. The current issues that we have encountered are mostly due to the low resolution of the pixy camera which prevents OpenCV from recognizing the dots at more oblique capture angles. If it were higher resolution, it would generate a more accurate calibration.

Robot Programming

This build, we successfully configured the RoboRIOs and programming computers to use the latest version of FRC software, albeit with a few hiccups. In techno-speak, the RoboRIO wasn't assigning itself a static IP address, leading to communications problems. The programming subteam was able to overcome this issue, albeit with a temporary fix.

FRC Day 1 Build Blog

Day 1: Kickoff & Testing

Today was the first day of the FRC build season. The new game, FIRST Steamworks, was revealed, and we began evaluating strategies and testing prototype mechanisms for our 2017 robot.

Helpful Links

The game manual and rules are linked below. All team members should familiarize themselves with the manual, especially the Match, Game and Robot sections.

Game animation:

Game manual.

Prioritization & Strategy

To evaluate potential strategies for our team, we estimated times to perform tasks such as picking up and depositing gears, collecting balls, hitting hoppers, etc. We then compared that time to the point value of each task to determine a priority list of items to prototype as well as to begin match strategy.

For 2 strong robots working together in eliminations, an optimal strategy could be to each perform a 2 gear autonomous and then in teleop do 2 “hybrid cycles” in which they each score both a round of 100 balls and a gear followed by 2 “ball cycles” where they score only balls. This would produce a maximum score (assuming 80% shot accuracy) of 410 points. Perhaps the third robot could play defense rather than contributing offensive points.

More information on this strategic analysis can be found in this spreadsheet.

Prototyping

Today, we started by prototyping various mechanisms to accomplish each of the tasks in the game. Later, we will work to evaluate the prototypes, determine which are most promising, and integrate them together for more comprehensive testing.

Shooters

High Throughput Shooter –

We discussed creating a shooter which can shoot a large number of balls very quickly (goal is 50 in 1 second). This will need to be designed, built, and tested in the coming week.

Single Wheel Vertical Flywheel – back spin –

We made a prototype for the vertical flywheel by modifying the hood of dropshot. We found that the shots often were inconsistent depending on the orientation of the wiffle ball holes.

Testing:

IMG_0439.JPG

Single Wheel Vertical Flywheel – front spin – We reversed dropshot and tilted it backwards to use the same flywheel but give the balls front spin instead of backspin. The balls still veered and had the same problem as backspin

Testing:

Double Wheel Horizontal Flywheel – This looks like the most promising prototype we have so far. It reduces spin on the ball to minimize the wiffle effect on trajectory. We are going to change this to a vertical double flywheel so that we can lengthen the wheel and shoot multiple balls side by side.

Testing:

Double Flywheel Prototype.jpg

Double Flywheel Prototype 2.jpg

Ball Intake – The preliminary plan is to have the bumper not at the limit of the maximum size so that we have room to deploy an intake in front of the robot (past the bumper, but within the maximum size). Although we could have a bumper gap, the maximum gap is about 14” and this setup would allow us to intake the full width of the robot which could be much faster and easier. It has been modeled in CAD and laser cut, but we have yet to assemble the prototype.

Catapult – A prototype was started for a spring-powered catapult shooter. This prototype needs some additional work to determine feasibility.

Gear Manipulation Mechanisms

Hook – We prototyped a one-way latch that is latches into one of the holes in the gear and then is pulled back into the robot to hold the gear with friction. This could then be actuated to tilt up and down to move from a floor-loading position to a hanging position. We made a new version with two hooks to allow for more misalignment when picking up the gears on the field.

Claw – A second prototype was built with two motorized wheels which intake the gear off the ground. The wheels are mounted to sprung arms which open around the gear as it moves in. It seems to work, but the quick prototype has the wheels spinning too quickly. We are going to work on slowing it down.

Drivebase – We have tentatively ruled out any sort of strafing drivebase because we don’t think it will be necessary. We will most likely use a 6-wheel or 4-wheel drive robot, as the team has high familiarity with these designs and should be able to construct them effectively and quickly. We are currently working on evaluating the best wheel configuration to have the ideal maneuverability by adapting Deadlift’s (2015 robot) drivebase with different wheels. We ran into some minor issues with radio connectivity, but we plan to fix this by using a newer radio. We need to finish the prototype.

Rope Climbing

Comb prototype – We discussed using a custom rope for hanging, likely a narrow, strong rope (like paracord) with knots. This prototype uses a comb-like hook to grab the knots and reel in the rope to pull up the robot and hang. We have tested it passively, but have yet to determine if it can support a robot’s weight.. There is still lots of work to be done, especially in optimizing the shape of the comb / spool so that the radius does not change too much as it rotates (necessary for gearing optimization).

Testing:

Programming

We started programming this season by creating a private code repository on Github based off what we did last year. We then started working on our demo boards, imaging them with the new 2017 firmware and installing driver station software to them. We also began experimenting with a Pixy camera for vision tracking. It seemed promising and easy to configure, but it didn't communicate easily with the roboRIO so more work is needed.

Bellarmine VEX Tournament 2016

By John Vu

This past weekend Bellarmine hosted its Annual Bellarmine VEX Tournament with a total of 69 teams from all over the Bay Area competing. Six teams from Team 254 competed against an assortment of designs and robots to make it past the qualification matches.

Team 254E enthusiastically discussing their strategy and reviewing the results from their last match.

By the end of qualifiers, three teams from Team 254 were moved into eliminations. During alliance selection, Team 254C joined Teams 5369 and 5327B to form an alliance. Team 254A, 254F, and 254C all competed in the quarterfinals, but only Team 254C broke into the semi-finals. Unfortunately, 254C’s alliance was eliminated in the semi-finals

Brandon of Team 254H makes adjustment on the robot after a match.

With three teams making it passed qualifiers, the tournament was a strong test, pushing teams and robots to their limits. The tournament’s intensity gave insight on the necessary improvements and adjustments that teams will need to make on their robots and strategy for the next tournament. Now, teams will continue working and improving their robots from the new insights from this tournament for their next upcoming tournament.

Students on Team 254H driving their robot during a match.

Congratulations to tournament winners 86868, 5776T, and 563.

2016 FRC Championship

Overview

This past weekend, from Tuesday until Saturday, we participated in the FIRST Robotics Competition World Championships in Saint Louis, Missouri. On Tuesday, a smaller group of students left early to set up the pit and make sure everything would be set up for when the rest of the students arrived on Wednesday. We were placed into the Newton division, and with Team 1241, Team 1731, and Team 708 we played some great games in eliminations, but unfortunately were eliminated in the subdivision finals.

Qualifications

On Thursday and Friday, we played 10 qualification matches across both days, and earned 9 wins and 1 loss throughout those games. In qualification match 100, we even managed to push a disabled robot onto the batter, securing us an extra ranking point and winning us the game with a final score of 140-139. The qualifications overall went well for us, as we earned 35 ranking points and ended up as second seed going into eliminations.

Eliminations, Einstein, and Awards

Saturday opened with the alliance selections, and we partnered up with the first seed team, Team 1241, Team 1731, and Team 708. With this alliance we hoped to consistently score highly while preventing the opposing alliance from having free reign on their side of the field. This strategy seemed to work out throughout our quarterfinal and semifinal games, with us scoring around 240 points in most of those games. In fact, we scored 254 points in our second semifinals game excluding foul points; however, a red card on our alliance prevented our score from being recorded that game. Moving into the finals, we matched up against an alliance including Team 217, Team 4678, Team 3476, and Team 188. Although we played hard, we were eliminated from the tournament in the Newton finals.

In the end, we would like to congratulate Team 330, Team 2481, Team 120, and Team 1086 for their success in winning the FIRST Robotics Competition World Championships. Additionally, we are proud of Team 987’s achievement in earning the Chairman’s Award, cementing them as a Hall of Fame team. Overall, we are extremely grateful to have had the opportunity to interact and play against many great teams at the Championships and hope to do even better next year.

2016 VEX World Championship

This past week, VEX Team 254C travelled to Louisville, Kentucky to compete in the 2016 VEX Worlds Championship. 254C competed in the Arts division at worlds. In total, there were four other high school divisions, each consisting of 100 teams from around the world.

254C discussing strategy with their alliance partners

By the end of the 250 qualification matches, 254C had won 6 of it’s 10 qualification matches, and was ranked 26th by alliance selection. Unfortunately, this was not enough to convince other teams to invite them to an alliance, and so their Nothing But Net season ended there.

254C's drive team watches their robot perform during the autonomous period

However, students have already begun to think about the new 2016-2017 VEX Robotics Competition, Starstruck, which will require a drastically different design from Nothing but Net.

Silicon Valley Regional Champion

This past weekend, we participated in the Silicon Valley Regional hosted by Google.

Qualifications

Throughout the qualification matches, the work we put in over the past few weeks payed off as we performed stronger in many areas than we had at CVR. We overall performed well, consistently crossing defenses and shooting high goals from the courtyard while earning a win/loss record of 8-0. Our success in the qualifications allowed us to place second in ranking moving onto the alliance selections.

Demonstrating Pit Display

Eliminations and Awards

During alliance selection, we went with the first ranked team, Team 1678, and Team 1662. With those teams, we went undefeated throughout eliminations and came out as the regional champions. During our second quarterfinal game, we even scored the highest amount of points in the tournament with a score of 205. Although we didn’t win any awards, we were honored to play with such great teams and are looking forward to the upcoming World Championships.

Central Valley Regional Champion

Team 254 just returned from the Central Valley Regional.

Qualifications

During the Central Valley Regional, from Thursday to Sunday, we competed with a variety of teams from all throughout California. Throughout the qualification matches, our robot, Dropshot, performed solidly, and despite one match with connection problems, it won 9 out of its 10 matches, ranking us at second place for the qualification matches. In our second quarterfinal match, we even scored 210 points, the highest score of this season so far.

Eliminations and Awards

During alliance selection, we joined an alliance with Team 1678 (Citrus Circuits) and Team 3970 (Duncan Dynamics). In our second quarterfinal match, we scored 210 points, the highest score of this season so far. We also made it all the way to the finals and won the regional, scoring 205 points in our first finals game. After the exciting finals, we also received the Innovation in Control Award for Dropshot’s targeting system. Overall, this tournament was successful for us, but we plan to continue iterating on our designs and improving shot consistency for the upcoming Silicon Valley Regional.

Dropshot Reveal

Team 254 proudly presents our 2016 entry into the FIRST Robotics Competition: Dropshot. Dropshot will be competing at the Central Valley Regional this weekend, followed by the Silicon Valley Regional and the last single FIRST Championship. More information on the robot.

2016 Duel In Diablo VEX Tournament

This past Saturday, VEX teams 254E and 254F travelled to Concord, to compete in the Duel in Diablo Nothing but Net VEX Tournament. At the tournament, they competed against 27 other teams from around the area.

Team 254E works on their robot between matches.

Both teams performed very well throughout the qualification matches. 254E, with just a single loss, finished the qualification matches ranked 3rd overall. 254F also performed fairly well, ranking 11th by the end of the qualification matches.

254F uses their match loads during a match.

During alliance selection, 254E invited 254F to join the third seed alliance. Due to the size of the tournament, each alliance only contained two teams. Unfortunately, this turned into a problem when the robots from 254E and 254F had issues, and there were no other robots to rely on. This led to the alliance being eliminated during quarterfinals.

254E & 254F strategize before their first quarterfinals match.

Despite not doing as well as they had hoped during eliminations, 254F was awarded the sportsmanship award.

2015 Tracy Triangle VEX Tournament

Yesterday, VEX teams 254B, 254D, 254E, 254F, 254G, & 254H attended the Tracy Triangle VEX Tournament. With over 80 teams, this was the largest VEX tournament our teams attended this season.

Team 254E lines up their robot.

Throughout the tournament, all 254 teams performed very well. By the end of the qualification matches, 254B had gone undefeated and ranked 3rd out of all teams. During alliance selection 254B invited 254F & 4768C to join their alliance. Additionally, 254H joined an alliance with 4768B and 4768. 254E also joined an alliance with 5772 and 5327C.

254F discussing strategy with 254G.

Unfortunately, teams 254B, 254F, & 254H were eliminated during quarterfinals. 254E made it through several challenging elimination matches, but ultimately lost in their 3rd final match by a small margin.

Students pose for a team picture.

At the end of the tournament, 254H was awarded the Create Award for their robot design. Congratulations to the tournament champions 5776T, 8000B, & 8000D.

FRC Kickoff

This Saturday kicked off the first day of the 2016 FRC season with this year’s game, Stronghold. After the initial game reveal, both students and mentors gathered in the robotics lab to analyze this game’s rules and come up with strategies to tackle this year’s challenge. Once kickoff wrapped up around 4:00, the team began work on designing and prototyping parts of the robot.

Students presenting strategy

2015 Willow Glen VEX Tournament

Yesterday, Team 254 for had the opportunity to compete in the Willow Glen Plaza VRC Tournament. VEX Teams 254A, 254B, 254C, 254D, 254E, & 254H had the opportunity to compete against 18 other VEX teams from around the area.

vex

Overall, all 254 VEX teams performed very well. By the end of the qualification matches, 254C was ranked 1st, and 254B was ranked 2nd. 254E and 254A also performed very well, ranking 6th and 9th, respectively. All 254 teams made it into the elimination matches, with the first seed alliance consisting of 254C, 254B, and 254F. Unfortunately 254D’s alliance was eliminated during the quarterfinals, and 254C, 254B, & 254F lost to 254A’s alliance during semifinals.

During the finals matches, teams 563F, 254A, & 256B went head to head with 563, 254E, & 6734B. After four exciting matches, 563F, 254A, & 256B won, due to a last minute strategy change that led to the 254E accidentally entering their opponent’s loading zone, which led to a disqualification.

Additionally, 254C also won the Excellence Award, and ranked first in robot skills at the tournament.

2015 Central Valley Nothing But Net Tournament

Last Saturday (12/5/2015) VEX teams 254C, 254B, and 254F competed in the 5th Annual Central Valley VEX Robotics Challenge. For all teams that competed, this was their 3rd tournament of the season, so it was a great opportunity to implement changes based on their previous tournaments.

Team 254B preparing for an elimination match.

Overall, all teams performed very well at the tournament. Throughout the day, all 254 teams were ranked highly, and were strong competitors. 254B ended the qualification matches ranked 7th, and was invited to join the 3rd seed alliance with teams 973A & 4033B. Team 254C went into alliance selection as the undefeated first seed robot, and picked teams 3396 & 973G to join their alliance. While team 254B unfortunately lost during the semifinals, team 254C was able to win all of their matches throughout eliminations, and ultimately won the tournament.

Team 254C poses with their robot, trophy, and alliance partners.

Despite not making it into the elimination matches, team 254F impressed the judges with their robot and strategy, and was awarded the Judges Award.

Team 254F & their alliance partners discussing strategy before their match.

This tournament was a rather successful one for Team 254, and everyone involved learned a lot. Teams will now return to working on their robots and strategies for the upcoming Willow Glen tournament.

2015 DVHS VEX Tournament

This past weekend (10/18), VEX Teams 254A, 254B, 254C, 254F, & 254E all competed at the DVHS VEX Tournament. Being the first tournament of the season, it was a great opportunity for our VEX teams to determine how their robots functioned during competition, and to test their strategies.

Team 254A making last minute changes to their code.

With their single flywheel design, and a strong lift, team 254C was eventually invited to join the sixth seed alliance, with teams 824C and 5327B. After several close matches during quarter\-finals, narrowly won and moved on the semi\-finals, where they were unfortunately defeated by teams 8000A, 8000D, and 5776Y. Congratulations to tournament winners, 5776T, 5369, & 5776.

Team 254C lifting their alliance partner.

Overall, our teams all had a lot of fun at the tournament, and learned a lot from other teams. Several of our teams now have plans to work to improve their robots for the upcoming Bellarmine VEX Tournament.

254 Featured in AT&T Documentary

{“data”:[{“type”:”text”,”data”:{“text”:”Check it out! Our FRC team is one of the five featured in this AT&T documentary of the World Championships in St. Louis!\nEven though we only made it to division quarterfinals, the event was great! \n\n\”RoboLeague, a documentary airing on AT&T U\\-Verse Buzz Ch. 1000, follows five FIRST Robotics Competition teams as they strive for glory at the 2015 FIRST Championship!\” \n\nhttps://vimeo.com/139506546\n”}},{“type”:”video”,”data”:{“source”:”vimeo”,”remote_id”:”139506546″}}]}