I didn’t realize you had transmissions. How often did you use them in a match? Would you be willing to talk a little about how they work? It looks like you are sliding the gears on the axle rather than moving the entire axle.
I would would also love to see the code and any more information you’d be willing to share about the sensor layout.
Thank you Highwayman. I am part of VCAT Robotics and worked on Pyro. Both robots used the transmissions pretty frequently over the course of the competition. On Pyro, there were about about 5 or 6 key instances where the transmission was very helpful. Pushing definitely allowed the robots to both grab the piles on the field (grabbing the orange balls) and going for the lift. We actually pushed one of the small robots with both of our robots about 2 feet into the box. We thought the ref would DQ them but they called it offensive on our side. We were still able to lift despite that and still won the match. Overall, we were able to push the really hard teams and really fight for those piles.
A little information about the transmission. Our transmission featured 6 motors set up for high speed with a 60:36 to a 36-60. The Shifter was located on the back wheel. The axle holds the wheel and the shifting gears. If you look closely at the video, you see the standoffs going from the outer chassis to the inner part of the gearbox. The shifting gears actually move along the standoffs as well as the axle. The only way to fit the standoffs through the gears are to drill holes through the gears. This eliminates that stress on the single axle and onto the stronger and more durable standoffs. The back piston extends and retracts, shifting both sides evenly and perfectly in order for both sets of gears to mesh, allowing the entire drive train to move simultaneously. Like you said, the shifting gears move along the axle with the use of the circular inserts inside the shifting gears. As far as the code, and any other information, the RECF is actually going to publish our engineering notebook so our whole process as well as the code can be viewed then.
Hope this somewhat helps
@Highwayman NP, the disks are spaced perfectly in order to create the least amount of friction as possible. Pyro actually has mechanical stops on the slide where the piston extends and retracts in order to prevent that unnecessary friction.
I hope you like it. It was a ton of work.
I’ve Uploaded the complete code that was running on PYRO (15" Red Robot) to git Hub. Some important aspects for Vex U is that autonomous is 45 seconds at one point it was a minute. For us it was important that we could change our autonomous quickly depending on our strategy. In order to do so our robots already had various routines programmed, plus our functions allowed us to program new routines rather quickly. Another important aspect of a 45 second autonomous is to be able to detect when something has gone wrong, we implement various fail safes in our code (mostly time outs) if a step is not completed within its allotted time then something must of went wrong and lets kill all the motors to prevent damage to the robot.
Here is a couple of the highlights of the code:
Autonomous selection menu for up to 5 Blue and 5 Red Autonomous and 1 Self Check code
If Debug mode is enabled, Skips autonomous selection and runs Debug code autonomous only
RPM Control (Bang Bang) Using Hall Sensor
Shoot Balls Based on RPM Error (Only when error is below tolerance)
Smart Intake/Feeder Control Using 4 IR Sensors
Turn Based on Gyro
Move Based on Encoders (Multitasking)
Move Based on time
Most Autonomous routines include Fail-safes to prevent damage on the robot if steps are not completed when expected
@PlanetPluto is there any particular aspect of the robot you are interested in or want to know more about? As far as pictures, everything will be on the engineering notebook. Because all of the members are currently busy, we haven’t been able to compile the whole thing with technical drawings and code included. However, you can expect to see it within the next week.
So the Smart Feeder uses 4 IR sensors in order to shift balls up in a stage by stage manner. The front IR sensor sees a ball and turns the feeder on until the 2nd IR sensor reads that same ball. Then the smart feeder moves to stage 2. The robot picks up a ball and as it is sensed by the front IR sensor, the feeder turns on and stays on until that first ball moves to the 3rd IR sensor. At this point the second picked up ball is somewhere behind that first ball in the feeder. The same process happens as a third ball is picked up. The first ball will then move to the fourth sensor and the feeder will turn off completely. All of this occurs automatically so that the user does not need a mechanical stop for balls to not get accidentally launched. All the user needs to do is press the intake button (whatever we choose it to be). For our case we like to use the Right front bumper. The feeder turns on and off based on the IR sensors, but the intake can always be moved or turned on. So now for the fourth ball… When the feeder completely turns off, the user can still use the intake to pick that fourth ball up. That fourth ball always has enough space on the ramp of the robot to not require the feeder at all, which is really beneficial.
There is always a problem of what if the robot picks up 2 balls but only “sees” one. In that case, we have a reset button for the feeder, and the feeder will move up manually for a bit until it reads the next IR sensor.
Hope this helps. I know it can get a bit confusing.
@Justice League 5233J
Thank you very much. Shoutout to Team44 a.k.a GreenEgg Robotics for inventing the same gear transmission system.
Sorry for bumping this but I wanted to ask the question that had been eluding many teams (including ours) for the entirety of the season. You said your flywheel was specially designed to have a specific weight, ratio, and material? What are the physics that go behind this?
What we did was set up a theoretical model using energy equations relating flywheel energy to ball energy and subsequently getting velocities from there, but there wasn’t a whole lot to understand beyond “more flywheel mass = good,” at least when accuracy was a concern. The understanding was more flywheel energy allowed for the smoothing out of bumps when it came to squish and mass variations. (This didn’t turn out to be the case- our 8 motor launcher with two 5" wheels gave a full court fire rate of 1 bps, at best… and fairly bad accuracy. Needless to say the violation of pure intuition with the fact that 8 motors had trouble keeping up shocked us)
Actually, looking at most designs throughout the season there appears to be a myriad of variables that could mess up accuracy:
How much the launcher compresses the ball
How long the flywheel spends time in contact with the ball (impulse)
Whether a team uses a springy hood, Lexan hood, one with a grippy material applied, etc…
High angular velocity with a slip condition or low velocity with a no-slip condition
Moment of inertia of the flywheel
And so on…
What considerations did you make when designing your launcher? It’s devastatingly accurate… at least compared to our little innocent launcher, anyways. I feel like NbN was especially lacking the M in STEM as far as scientifically-and-experimentally-verifiable flywheel physics goes.
@5059 - Dan
The launcher was designed to have a specific wheel weight and compression with the utilization of 1 25:1 gear reduction with 4 high speed motors. Although a lot of math was involved, a huge portion of it was trial and error. Although energy equations can be used, it doesn’t account for the efficiency of the motors. Two equations used (linear velocity and angular momentum) allow us to determine what is necessary to maximize distance from each launch. Linear velocity tells us that L = rw (where r is the radius of the wheel and w = RPM0.10472). This means that larger radius wheel = larger Linear velocity. Since we are college, a 4 inch wheel was pretty much the highest we could go before exceeding our limitations. In order to maximize arc and distance, we looked at angular momentum. Angular momentum uses both wheel radius and mass. Using a constant radius and varying masses, we were able to get an appropriate angular momentum. It should also be noted that because a single flywheel only uses a single wheel, there is a lot of friction that occurs on the back of the launch (this creates backspin on the ball but also causes a significant amount of energy lost). A dual wheel launcher would not have this problem, but the arc definitely won’t be as great as a single flywheel.
Using different masses, the Bang Bang algorithm was used to determine which wheel mass had the smallest recovery time between launches. What this means is that with each launch at a full court setting, the launcher would need some time to recover to get to its optimal RPM before launching. The code made it so that the launcher would not launch unless the RPM was at its optimal setting. This was huge for us throughout the competition, and to my knowledge we had the fastest launching rate for full court in both VRC and VEX U. Using 4 different wheel masses (200, 300, 350 and 400g), we ultimately chose the 350g wheel. Although theoretically it is best to use the heaviest wheel, the 350g wheel gave the best results in terms of recovery time and allowed for the fastest launches. This makes sense since the 400g wheel was too heavy for the motors to handle, especially with Bang Bang code.
Compression is huge, especially with varying ball densities. Only certain launcher types are actually affected by ball density, including the single flywheel. Because of this, compression had to be brought to a minimum. There is approximately a little less than 3/8 inch of compression. This was ultimately determined by trial and error, and it just worked out that way. It’s extremely difficult to model the system mathematically, since a lot of it is only theoretical.
Believe it or not, a huge portion of this project was programming. Without the Bang Bang algorithm, the launcher would not have worked the way it did. We would not have been able to launch within 400ms per shot and as consistent for that matter. There were teams that definitely struggled getting the mechanical part right. Many teams did get it right. The hard part was using the mechanical system and implementing the code to make it work better than the rest.
You’re right, there definitely is a lot lacking in terms of STEM. Engineering is also really important. Having the ability to CAD the robots was such an advantage for us, being able to condense complex mechanisms into smaller and lighter versions. The math behind certain mechanisms really needs to be understood so that teams don’t spend the time testing hundreds of mechanisms and instead pinpoint a few at max.