Thanks for the heads-up. I’ll look into that. I’d assume FRC would encourage teams handing down engineering design and build information year to year. I’ll get up to speed on the spirit of the rule.
As long as you make your design public (which you just did) and you make new ones during the build season, you are generally okay. Just don’t use anything that has been prefabricated. Of course this years rules could always be different…
Absolutely!
Though, this may just be me, but if I’m going to build modular drive units, and I have experience with CAN bus encoder feedback control, I would build swerve modules that aren’t specific to which corner of the robot it’s placed on, such that I could build 6 modules per robot I build and have spares that can be placed on in the event of a module failure.
Otherwise, I would look at maybe an octocanum system that uses pneumatics to switch between the mecanum wheel and a traction wheel.
Experience tells me that Mecanum doesn’t exactly help you in the eliminations draft, as teams get wary of defense being played on you or you being unable to play defense.
I’d love to build a swerve drive. I agree it’s the best technology. But, we can’t afford a Cadillac.
The prototype we’ve built works reasonably well given the relative simplicity vs. the swerve design. We tested the prototype with 4" regular wheels and the reduction in power (tank mode, forward) wasn’t too bad. Our thinking is to make the drive system very doable for the team and allow more time/resources for the game functions.
I’m bugging my son to make a video of the Mecanum teleop to post. The kids are able to control the thing with amazing agility. I guess the years of video gamming is good for something.
“One of the purposes of the FRC is to provide Team members with the experience of conceiving, designing, and constructing their solution to the annual competition challenge. We want each student to have the experience of creating a new system each year… Solutions that merely bolt together a minimum number of externally-designed COTS subsystems may not offer the students the opportunity to understand the “why” or “how” of an item’s design. Likewise, solutions that are merely minor modifications of a design utilized for a previous competition does not offer the current students complete insight into the full design process”
Re-reading the FRC manual from last year, what do y’all think of this approach:
Maintain good design documentation; drawings, specs, fabrication details…
Review previous design vs. current game requirements: gear ratio, speed vs. power, agility, etc…
Keep previous year’s design elements if no advantage in changing system
I’m sure each team will add improvements if basic design is retained. I don’t see any difference in using AM Mecanums & ToughBoxes from previous year’s design. There’s plenty of opportunity for the students to experience the engineering process with the other game functions. After years of building clean-rooms, I avoid “reinventing the wheel” whenever possible.
I guess the key is:
“Purchasing optimization and design re-use are both important concepts; however, Teams must be cautious not to over-utilize them to the point that the student’s experience is compromised.”
Yup, probably one of the hardest things for me when I was starting into mentoring is to remember that, unlike in industry, the point isn’t always to get the thing done the fastest and most efficient way. The point is to teach why it’s done that way, even if it means doing it less efficient way, and doing it that way over and over.
I usually make the student do it the hard way the first time (or the first couple times). And then, once they’ve done that, show them the easy way.
I make students tap things freehand when they’re new, and then once they’ve tapped four or five parts like that, and they get frustrated from having to constantly make sure that the tap is going in straight, I introduce them to the tap guide block that does that for you.
I don’t think that posting a couple of screenshots counts as making the design public as far as reuse goes. In my mind, a cad model or a set of dimensioned drawings would be required.
Unfortunately, last years rule requires that the design be public before kickoff, even though the rules and any chance for clarification aren’t available until after kickoff. I think that any rule that governs something before kickoff should be available before kickoff.
I agree about the after kickoff rule issue completely. I looked at their images and I’m pretty sure that I can build that without more information, which speaks to the simplicity of their design.
Either way I don’t think that part would matter, as these modules as pictured wouldn’t be up to the task of FRC in my opinion.
We’ll be publishing all specs, drawings & code as design progresses. If anyone would like specific information, let me know…
Were not posting design to meet FRC rule requirements; intent is to share ideas for collaboration. There are many pesky details, particularly with coding, where solving problems could benefit everyone. We’ve yet to work out the CAN Bus/Jaguar CAN Bus encoder built in control functionality to do what we’ve done with the FTC NXT/Matrix prototype.
Excellent advice! It’s a beautiful thing to see the kids go from almost no fabrication ability to understanding, and then ownership of the build. It’s very rewarding when they “push me out of the way” and take off on their on.
This reminds me of a time, right out of school, when I was doing some simple machine design work. I would bring my half-baked shop drawings to an “old school” machinist who was trained shortly after WWII. He was very kind to me and spent time going over the drawing details and explaining why my tolerancing was poor. He’d make one beautiful hand drawing in seconds that contained more information than my 3 CAD drawings I’d spent hours on.
One day when he’d accepted my drawing with no corrections, he said:
“Craig- let me show you something”
He brought me into the back of the shop, pulled back a curtain revealing a part he was working on; an amazing steel object that looked more like art than machine. He said:
“My first task in machinist school was to take a file, vice and piece of steel and make a machine screw to spec tolerances. Now at the end of my career, I’m given a high-tech, super-computer design that has no geometries that can be mathematically derived. I’m roughing the shapes with the CNC and am finishing by hand filing. The young machinists want to skip the manual work and do everything by computer…”
This was one of the most enlightening experiences of my life.
I don’t think the design itself is weak, simply that the current version posted would be up for quite a task. I have no clue as to speed, but I would be concerned with the gearboxes (we have found planetariums to be a tad fragile) in a pushing match. An open frame with little structure to tie the front end together would have me concerned as well for impact, but I think with the scale of your frame rigidity shouldn’t be much of an issue. Again, these are simply in the prototype you have proposed. I haven’t a clue what this could delvelop into when built for FRC. I am excited to see what it could become, as a modular approach is something we have been contemplating for our entire history in FRC.
Beyond that, it’s a tiny little thing! Sure does make the battery look massive! (I know it is a prototype!)
I guess my post is unclear. The prototype is the FTC team. We’re scaling up for FRC. The FRC battery was used to add weight to simulate future game components. The open frame was min structure for testing drive performance
No you are good with your clarity. But only having smaller scale design to base my opinion on, I simply pointed out my concerns. I think this has great promise and am excited to see what the FRC scale version is capable of.
