That’s awesome looking. Thanks!
Do you have any video of that intake picking up cargo from carpet and against the wall?
David
1 Like
This is the quality testing I’m here for. Your drivers are going to be super happy.
21 Likes
12 Likes
Thanks! (And send my regards to building maintenance…)
David
5 Likes
Calling @bbonner…
(Since I don’t think Keith is here)
We are lucky enough to have a fantastic workspace but we also “get” to do our own maintenance
2 Likes
As promised, attached are our redesigned business plans for FRC and FLL. Students had a rough path condensing from 49 pages 
to 3. Feedback welcomed.
(Three appendices - org chart, SWOT graphic, and balance sheets - will be included in the final version.)
6328 2021-2022 FLL Business Plan.pdf (719.0 KB)
6328 2021-2022 FRC Business Plan.pdf (669.5 KB)
2 Likes
Eh, we only had a student actually drive a robot through the drywall that one time…
Actually as a result of that incident most of the walls in our drive space now have wood/plywood up about 3’ - including the wall shown in the video above, thankfully! Though recent drive practices have lately been “helping” me find all the spots I still need to cover. 
2 Likes
Software Update #3: “Follow the yellow brick trajectory!”
This week, we now have a drivable robot, a prototype intake, and a motion profiling system ready to go. What is there to do but write a few auto routines? Even without a shooter, we can still test most of the important functionality. After some discussion with the strategy team, we began work on the following routines:
- One cargo (from any position)
- Two cargo (collect any of the three cargo around the tarmac)
- Three cargo (collect two cargo from the lower tarmac)
- Four cargo (intake one from the terminal)
- Five cargo (intake from the terminal, including the HP cargo)
See the videos below for the three, four, and five cargo autos in action.
Five Cargo
Four Cargo
Three Cargo
(The three cargo test had an extended shooting duration.)
The Flywheels
While we don’t have a shooter on the robot yet, we know enough about the design to control it in software. The structure of the subsystem code allows the hardware to be replaced while preserving the control logic — we can switch between SparkMAX and CTRE motor controllers, disable the hardware in replay, or turn it into a physics simulator. Throughout these tests, the robot is running the flywheels in a simulation, meaning the routine can check if they’re up to speed when shooting. We use the WPILib FlywheelSim class. The graph below shows the flywheel speeds produced by the robot during the video of the five cargo auto. The red boxes show when the feed system was “running.”
The Paths
We decided to position the intake and shooter on opposite sides of the robot, which makes these routines much simpler. The three and four cargo paths are fairly intuitive, as they aren’t significantly limited by time. On the five cargo path, we considered two possible ways to run the routine:
- Shoot one cargo immediately, collect two from around the tarmac, shoot two, collect two from the terminal, shoot two.
- Collect one cargo from around the tarmac, shoot two, collect one from the tarmac, shoot one, collect two from the terminal, shoot two.
We ended up going with the second option for several reasons. First, shooting immediately requires waiting for the flywheels to spin up. While this may happen quickly, we don’t know for sure right now. Second, moving between the two cargo around the tarmac in a single path is tricky. With a differential drive, the fastest method seems to be a “back up and turn,” which is complex and still inefficient.
Another unknown variable is the time required for shooting. While the three and four cargo routines can be fairly generous by sitting still for multiple seconds, we don’t have the same luxury during the five cargo auto. The middle shot (with one cargo) requires that the feed be timed such that the robot continues moving. We may take a similar approach with the other shots as well, depending on the speed of the feeders.
As we haven’t yet mounted a camera to this practice bot, we aren’t using vision to aid with odometry tracking. The trajectory constraints are therefore tuned to reduce wheel slip as much as possible — in the future, we hope to adjust these constraints to shorten some of the paths. This may allow us to spend more time shooting or intaking from the terminal during the five ball auto.
Full Simulation
The robot was using simulated flywheels while running the routines, but we can also run the autos entirely in a simulator for testing. The video below shows the five ball auto running without a real robot at all.
As with the flywheel, this is as simple as replacing the hardware implementation of the drive with a physics simulation. We use the WPILib DifferentialDrivetrainSim class. Running the routine in a simulator allows us to iterate very quickly, and it means we’re more confident that everything will work when we test it on the real robot.
Code Links
- Motion profiling command (here)
- Five cargo auto (here)
- Four cargo auto (here)
- Three cargo auto (here)
- Two cargo auto (here)
- One cargo auto (here)
We’ll continue to work on refining these routines in the near future, like making sure that they stay clear of the lower exits to the hub. In the meantime, we’re happy to answer any questions.
-Jonah
35 Likes
In past years, we’ve gotten incredibly useful feedback from doing practice Chairman’s presentations with other teams. In the spirit of Open Alliance, we’re working with 7407 to pilot a
Chairman’s Alliance project so more teams have that experience. We’re hoping to bring together a few teams (virtually) to run through their presentations, field practice questions, and receive actionable feedback, all led by an experienced facilitator.
These practices are meant to be working meetings and presentations are expected to be rough drafts. We’re scheduling these early enough that teams can to incorporate feedback and still have plenty of practice time before their official Chairman’s presentation.
Is this your team’s first year presenting for the Chairman’s Award, or are you a rookie team? We invite you to come observe, learn, and ask questions. Sign up through the registration form.
We will do our best to accommodate if there is a date/time conflict so don’t hesitate to sign up if it’s just the exact date that’s the barrier.
The first practice will be Tuesday Feb 22 for teams that are presenting at Week 1 or Week 2 events. Teams that are presenting later are welcomed, of course, but we know that presentations may not be ready even in rough draft that far in advance. If there’s enough interest, we will organize another practice in mid-March.
More info in the registration form.
4 Likes
Simple, Flexible Motor Test Rig
Going into this build season, we wanted a simple way to operate motors on prototypes. Before we went mostly brushless in 2020, we’d hook up prototypes to the Talon SRX’s on a kit-bot, but that was always a little clunky. For 2020 prototyping, we ran Neos’ SparkMax controllers on a janky SB50-to-PowerPole cable without overcurrent protection, each controller hooked to a laptop to run the Rev application. For efficient and safer prototyping we needed a better solution.
For prototyping complex assemblies, we knew we needed to run multiple motors at once. Commercial single-channel PWM solutions, like the Thrifty Throttle, were not cost effective in a 4-channel configuration. At the other extreme, we could have built a mini-control system around a Rio and done full-up control of however many motors we wanted, but we didn’t have a spare Rio nor did we want the complexity of needing robot software and a driver station just to run motors.
Fortunately for us, capable microcontrollers are ubiquitous and cheap! We settled on a 4-channel solution, which could be run on a standard Arduino Nano. To keep complexity down, there’s a simple set of physical controls: each channel has a button to toggle it on and off, an LED to show its state, and a center-detent slider for speed control. While this is overall a pretty simple build, we’re sharing it here in hopes it may be useful to other teams, either to build as-is or as a starting point for a different variant.
Control Board
Here’s the schematic of the control board. Note that pins 2 & 3 on JP1 through JP4 are reversed; the PWM signal should be on the third, not middle, pin.
And here’s a picture of the board, which one of our students built with point-to-point wiring on a stock prototyping PCB:
Arduino Code
The control software is a quick sketch of around 100 lines:
This uses the standard Servo library for generating the PWM signals; this works very well for driving FRC controllers’ 1000uS to 2000uS pulse width inputs. Channel state is toggled based on debounced reads of the buttons. The software continuously scans the analog sliders and scales the values to the appropriate PWM value.
Power Distribution & Motor Controllers
Of course, the control board is only half the solution; we need motor controllers and a safe way to power them. For four channels, we used these power bus bars
and a set of cheap automotive-style self-resetting 40A breakers.
You can, of course, use whatever controllers you wish. Initially we built the board with two Spark controllers for brushed motors, and two SparkMax controllers for brushless. This allowed us to use either motor type without having to switch modes on the SparkMax’s; we feared that if left in the wrong mode we could easily damage a motor. Almost immediately, of course, we needed to run a prototype with 3 Neos. That wouldn’t be the last time, so we added two more SparkMax’s; with PowerPoles on both the Sparks and the SparkMax’s, it’s quick and easy to use either type (though it made the wiring look less neat than in the original build). The four PWM outputs on the control board can likewise be plugged into whichever controller is needed.
Final Product & Usage Notes
Here’s the finished build. It’s perhaps not the prettiest thing in the shop, but it is very functional and adaptable.
Some prototypes need motors running at the same speed; a Y cable can be used to run two controllers from one channel. Sometimes those motors need to rotate in opposite directions. Brushed motors, of course, easily achieve this by swapping positive and negative leads. For brushless, we use the Rev hardware client to reverse the output on one of the pair and save the configuration to flash.
Cost
The main cost of this rig is in the motor controllers. In our case, we had Sparks in a drawer, and two of the SparkMax’s had previously had a issue of uncertain origin that caused us to flag them as “not for competition use” anyway. A Nano clone was about $5, most of the small electronics parts were on hand, and we spent less than $50 on the rest.
Known Issues
Sadly, we did not include a hyperspace control.
16 Likes
CAD & Design Update
Sorry for the delay in posts, we’ve been super busy finishing up the design and getting all the facts straight. We’ve been making and assembling lots of parts already too, but that will be saved for a slightly later post to keep this one resonable.
Top-level Robot Design
We’re still putting some finishing touches on the climber and are hoping to put forth a lot of effort into a high-rung climb after we have most of the robot assembled and running. Ideally we’d have a group of mentors & students devoting the majority of their time to that while the rest of the robot is being manufactured & assembled but due to our current mentor & student count, that’s unfortunately not entirely realistic for us.
Overall, we’re pretty happy with how modular the design turned out. Thanks to the gusset+tube construction style that we’re utilizing more of, we should be able to fairly easily adjust portions of the design when something inevitably doesn’t work / breaks / etc.
Specifications
Overall weight: ~94.702 lb (not including battery or bumpers)
Onshape predicts our robot to be roughly 110 lbs, which gives us at least some headroom for the rest of our climb and whatever high-rung mechanism we come up with.
Center of mass
We think that it’ll be important for our drivers to just be able to punch it and not have to worry about the robot tipping (a couple of software mechanisms will help with that as well). Hopefully this can get even lower with any ballast we add to get up to 120 lbs.
Length x Width x Height: 30x29x40
Banana for scale (except it was just photoshopped in and may not be the correct scale).
Motors: 14
- Drivetrain: 6 NEO
- Intake: 1 NEO
- Hopper: 1 NEO 550
- Tower: 1 NEO 550
- Feeder Wheel: 1 NEO 550
- Flywheel: 2 NEO
- Climber: 2 NEO
Drivetrain and Electronics
Intake
There haven’t been too many changes made to the intake since our last update post, but we were able to shorten the link lengths which should help reduce at least some of the floppiness.
As in our prototype videos, we’re also using a dropdown bar - we found that this helped our prototype apply more favorable compression on the bumper, so we’ll be sticking with that for our final intake as well.
The dropdown bar starts spring loaded up via surgical tubing - it will be knocked down by our intake at the start of the match, at which point the surgical tubing over centers and is consequently spring loaded down throughout the rest of the match.
Gear ratio: 60:16
We picked this to be roughly in the right ballpark from our guess while packaging in a N:16 for our prototype and it worked well enough that we didn’t feel like we needed to change it. The top roller, however, is just slightly slower than the other 2 rollers - the hope is that this will help reduce the tendency for balls to jump out the top of the “hopper” area.
“Hopper”
Hopper is probably the wrong term here as all it does is center the balls and not store them, but for lack of a better term that’s what we’re going with.
We had good success with this in our prototype testing and were surprised that it worked pretty well with balls entering from the edges of the intake. There will be some adjustments that we’ll need to make when it’s actually on the robot (the height of the omnis, maybe the distance between the omnis and the bumper, etc.) and we may end up adding a couple pieces of polycarb around the “hopper” if we encounter issues with cargo bouncing out of the robot.
Shooter
We chose to go with a tube-style hood (as opposed to plate) so that we’d have an easier time fixing any small issues that we may encounter with locations of rollers/cylinders/etc., as well as potentially improving it as the season progresses.
From our testing, it seems like a top roller helps improve consistency and removes some of the backspin that the main flywheel imparts on the ball - something that may (or may not) help reduce the likelihood of cargo bouncing out of the goal.
Right now the CAD shows the top roller being controlled independently of the main 6” flywheel - the hope here is that we can get more flexibility in the speed & the amount of backspin that we put on the ball, which will hopefully let us control our shot trajectory a bit. This seemed to work from our prototype testing, but we’re a bit nervous that them being mechanically separate may lead to shot inconsistency due to the recovery time of each being different. If this approach ends up being unsuccessful, we’ll just belt the second motor to the 6” flywheel and print that double pulley with a hex bore instead of a bore for bearings.
Tower
The tower is copied from our prototype tower/shooter and simply swapped to the real construction style. The exact control scheme for how we will index the balls in the hopper is tbd after playing with it more, but we have a few ideas involving 1 or 2 beam break sensors.
Climber
The climber is a single stage telescoping with a 2x2 outer tube and 1x1 inner. It’s pulled up by constant force springs and winched down by2 NEOs through MAXPlanetary gearboxes. The stages slide on two 3D printed blocks, the top of which has bearings pressed in on pins. There is a WCP shifter shaft and PTO kit block to act as a break which goes directly into the MAXPlanetary output.
There is still the most work to do to finalize the details here before manufacturing. We will also be adding (at some point) a set of passive tilting hooks to have a 2013 style High/Traversal climb (or at least that’s the dream). More details to come in a later post.
Design Reviews
We didn’t immediately arrive at this design, there were many small (and not so small) iterations which were made before actually manufacturing a first revision. Look out for a post soon going through some of the changes which were made to lead to what you see now.
-Max
Me when Onshape won’t load and the CAD is just a bunch of huge blocks
29 Likes
Great writeup.
Singulator is the term we use.
5 Likes
Same here
6328 Mechanical Advantage shows off their impressive 3, 4 & 5 ball autonomous routines, provides an overview of their completed CAD and details their robot assembly https://youtu.be/NUEpCExVE2Q
8 Likes
10 Likes
Can you all talk more about how this is working out for you and the process you use to get this command to work with SysID?
2 Likes
The SysIdCommand communicates with the SysId logger using the same NetworkTables protocol as the standard SysId robot code. Essentially, we just looked through the source of the project that’s deployed to work out the protocol and provide the same data. When using the command, we connect to the robot using the “logger” in SysId while skipping the “generator.” When starting each test, we enable the robot with the correct auto routine selected; the rest of the process is identical to the standard usage of SysId. This process worked well for us and definitely saved time compared to figuring out the project configuration each time. We didn’t notice any significant difference between the values generated by SysId using the standard project and our command.
Ultimately, we found that we only ended up using a very limited set of values from SysId: kS, kV, and track width. Given the relative simplicity of calculating these values based on the raw data, we realized that the process of running SysId was more time consuming than necessary (running a separate application, doing more tests than necessary for track width, saving and reopening the data, etc). Instead, we put together the following commands which handle analysis directly on the robot:
- FeedForwardCharacterization - Calculates kS and kV using a quasistatic test.
- TrackWidthCharacterization - Calculates track width by spinning in a circle.
These are set up as auto routines (here), and the results are printed directly to the console after the robot is disabled. We’ve found that while this process doesn’t match the more advanced capabilities of SysId, it’s a much better fit for our needs. Running one of these tests is now trivial since they’re always available with no extra setup. For example, this means that we could quickly check for mechanical changes during a competition in case of issues.
It seems like we removed the original SysIdCommand when we switched to the new characterization commands. I’ve added it back as reference or in case we change directions in the future. It’s available here.
Jonah
14 Likes
Chairman's Update
Really proud of our Chairman’s team this year. We have a very experienced crew (mostly seniors) who have been working with a Shadow team to transition their knowledge and process in the name of team sustainability. The written submissions were actually completed a bit ahead of schedule (unexpected for anything about FRC!)
Next steps:
-
Fill out the presentation script and PRACTICE PRACTICE PRACTICE (we are presenting at a Week 1 event)
-
Pull together the video in the next 10 days
-
Chairman’s Alliance practices next week over Zoom with the teams that signed up
2022 Chairman’s Submission 6328.pdf (661.2 KB)
4 Likes
Initial Design Iterations
Our high level robot concept has been the same for a while, but there are tons of updates to the lower level details. This post walks through where we were before and the high level feedback which lead to our design changes. This feedback comes from a combination of internal discussions and reviews with @davepowers. There’s tons of small details which we weren’t able to cover here, but this touches the major ones.
Starting State
At first glance this looks very similar to our current design, but without much of the assembly details there.
Tower
Feedback: Try and minimize the CG as much as possible. The tower can comfortably hold 2 balls already, so it should be able to shrink down without issue.
Result: Lowered the tower height by 6 inches which results in one ball being held at the top of the tower and another on the curve at the bottom. This was a remarkably easy change (updating 1 number) in the CAD due to how we derive the top level geometry of the robot off a main sketch. We expected everything to explode when doing this, but it somehow updated without issue.
Shooter
Feedback: Minimize the weight at the top of the tower.
Result: Removed the top 2 motor mounts and made the different belt spacings in line with each other at the bottom. This limited us to 2 motors between the main flywheel and hood wheel, but this seemed more than sufficient from our testing.
Intake
Feedback: The intake arms are incredibly floppy side to side
Result: This was by design, but it was still somewhat crazy. To reduce this we shortened the main link with a shorter belt, which moved the pivot point closer to the frame
Feedback: The drop down bar pivot is also very long, it should be able to have it’s pivot moved much closer to the bumper.
Result: In looking at the geometry again, it was possible to move the pivot point of the passive drop down bar to the mounting plate the piston pivots from, making the drop down bar much more compact.
Hopper
Feedback: The cross bar currently blocks the electronics, we should try to minimize components in that area to make access easier.
Result: The hopper became mostly two independent parts, with only a belt crossing the center. This made it much easier to access the compressor and pneumatic hub without taking the hopper fully off.
Next Steps
We should be mounting the climber which is the last major component on our robot tonight and will be sharing the final robot shortly once everything is running.
-Max
25 Likes
19 Likes