Yes, on the barrel racing path the robot follows around half of the circle. We found that it’s slightly faster to create a normal spline on the other side (as opposed to a full circle) since we don’t need to worry about navigating tightly around the marker. In general, we try to use the circles only when it’s necessary to maintain a certain distance to the marker. I’ll let @came20 answer the FRCKit question.
FRCKit is still very much in development, and I haven’t decided on the best way to make it available to teams in an easy way yet (this could take quite a while). Nevertheless, here are some instructions to get you on the right path to using the path visualizer:
I publish FRCKit library files to my own maven repository for ease of development. Thus, you’ll need to modify your
build.gradle file to talk to my server. See here in our 2020 code for how to do that.
Once this is done, you’ll need to pull in the dependency for the visualizer. This line does that (note that it goes in the
dependencies block that should already exist in your
build.gradle. Note that the latest version at the time of writing is
0.0.30, so I’d recommend switching out the version that’s shown in that line to
The visualizer is used by creating another
main method somewhere in your project which launches the visualizer. VS Code should let you run this method straight from the IDE once you’ve created it. From there, it’s just a matter of creating a
TrajectoryVisualizer object, passing it the parameters it asks for (the constructor is documented so you can just look at that for the parameters needed) and calling
start on the object you created.
Please let me know if you have any questions or trouble getting this working!
Thanks for the reply! We will give it a try. The visualization looks cool.
We got the visualization working. The students love it. Your instruction is easy to follow and we use the sample code from Team 6328 to test it. One pc complains about VC++ runtime. We uses version 28 but failed to use version 30 because the data type changed . After that, it works well. FYI, our team uses Talon FX, Pigeon and meter as unit. After some tweaks, we can get Team 6328’s motion profile wrapper to work. Thank you all for the helps.
FRC 6328 Mechanical Advantage Leadership and Project Management Training-2021 Season
On Mechanical Advantage-6328, we’re always looking to improve, whether it be our robots, capabilities, processes or our members. As you know, managing a team of 40 can be difficult. For the 2021 season, these challenges have been compounded due to COVID and the need to be socially distant.
As a result, the team identified an opportunity to build up the leadership and project management skills on the team. With the guidance of a new mentor, 6328 created and delivered two training classes to address this need. Both classes were structured to introduce the concepts, tie examples to FRC, and provide a forum for open discussion.
The first training series was Leadership, which was delivered in the fall. The goal of this class was to provide the tools that would help team members become more effective leaders. In addition, we wanted students understand their strengths as a leader, and through self-reflection, identify areas where they wanted to build on their skills.
This was modeled on classes that students may receive in Business school or professional seminars.
Leadership training was presented over the course of 7 weeks, each session was 1 hour. The following topics were explored:
- What is Leadership?
- Being a Role Model
- Goal Setting
- Decision Making/Problem Solving
- Facilitating Meetings and Events
- What Kind of Leader are You?
In total, 14 students participated in the Leadership training, and the team made it mandatory for the leads to complete.
Link to the materials: https://littletonrobotics.org/remote-learning/frc-leadership/
Project Management Training
The Project Management class was designed to introduce students to basics project management concepts and provide templates and tools which can be used to more effectively manage their work.
Following Project Management Institute (PMI) standards, students were instructed in how to scope projects, build project plans, and monitor to ensure results are delivered on-time. The class also stressed the importance of anticipating, managing and remediating risks. Finally, the class was intended to establish a common language across the different sub-teams for executing the work at hand.
We have applied these concepts to managing the teams’ efforts around Infinite Recharge at Home and the Game Design Challenge. We’ve also used this to organize and drive the Outreach and Award Submission.
Each week, Team Leads present to the mentors and describe the overall status of their workstream (Green/Yellow/Red), progress made, planned activities and a discussion of any risks with mitigations. In these sessions, dependencies are identified and coordinated amongst the different teams. We will continue to build on this to further standardize on weekly reporting and broaden our capabilities.
Conducted in January, the Project Management training was delivered in 2 x 1 hour sessions to 7 students. It was required for the team leads, and open to all who wanted to attend.
We look forward as an organization to building on our leadership and project management skills, which will give us an even bigger “Advantage” in the future.
Link to the materials: https://littletonrobotics.org/remote-learning/frc-project-mgmt/
Please do not hesitate to contact us for any questions.
One area we haven’t really talked much about is electrical. So, I thought it might be time for a post about things that have worked well and not so well for 6328. Your team may make different choices – but maybe you’ll get an idea or two!
Focus on Quality Wiring
The quality of the robot’s wiring matters. As I caution the students, just one bad connection can mean a lost match! Electrical is a great place to involve your most detail-oriented team members. Sloppy wiring not only puts your robot at risk, but it leaves a poor impression with judges, inspectors, and scouts. (When I’m walking around the pits, both the high quality and the poor quality wiring stand out immediately.) What makes good wiring?
- Right gauge and color wires
- Wires of proper length – neither stretched tight nor with large extra loops
- Neat, bundled and tied-down runs, kept as accessible as possible within the limits of the robot design.
- Tight, properly done crimps
- No exposed copper
- Serviceability – disconnection points around controllers/motors
- Carefully and securely mounted components
Like many teams, we started out using premade 6ga wire harnesses, but quickly moved to building our own made-to-fit main power leads. Unfortunately, standard 6awg wire is hard to work with and to route in the robot. We like to use “ultra flexible welding cable” – which is high quality wire made with smaller strands and nice rubber jacketing. This is so much nicer to work with! It’s only a little more expensive, and since you typically keep these runs as short as you can a 25’ length should be good for building a bunch of robots. Here’s our current PDP showing the main power inlet and connections; note how the flexible cable bends neatly into place. The dual red lead at lower left is the run to/from the main breaker.
Wire & Power connections
We use red/black zip cord for all power circuits; it’s far easier to manage than individual leads. High-draw motors (drive, shooter flywheel, etc.) get 10awg wire to reduce voltage drop and wire heating.
For power connections, unsurprisingly, PowerPoles are our standard. We generally put them on both inputs and outputs of motor controllers, and on motor wires, so it’s easy to swap a failed component.
As good as they are, PowerPoles can go wrong in two ways:
- Bad crimps. To avoid these, start with a quality crimp tool – we use a TriCrimp – and teach students to use it properly. It’s critical to inspect and tug on every crimp before assembling the shell onto it so that bad crimps are found before they’re in the robot!
- Shell assembly. When assembling PowerPole shells, the contact must fully “click” into place, otherwise it will not contact a mating connector. As with crimps, any problems are best found now! Fun story: Our rookie year we ran a 3-motor gearbox through an entire event and a half before discovering one of the motors wasn’t actually connected because of a not-quite-clipped PowerPole contact. It made for a great lesson in pit electrical debugging, but also demonstrated how properly tuned software helps – the robot actually ran fine, it had compensated by running the other 2 motors harder!
Pneumatics wiring involves running many pairs of small-gauge wire from the PCM to the solenoids. We use a piece of (stranded, copper) network cable, which contains 4 wire pairs and makes for a very neat run. Heat shrink the individual connections, then make a “boot” with a larger heat shrink to tie it all together. Be sure to label the pairs. A 6328 pneumatics harness looks like this:
If you need more than 4 pair, just add another piece of network cable and bundle the network cables together. Done well, you’ll end up with a nice, neat assembly like this monster manifold with 6 dual-ended solenoids in our 2018 robot. If you look closely you can see that each connector has a color code written on it, matching the twisted pair it’s connected to.
775 Pro Motor connections
We’ve used 775 Pro’s a lot on our robots but wiring them was always a hassle. Their terminals are really too small for the amount of power they draw and making solid connections, especially to 10awg wire, was hard. We used to build custom flag terminal assemblies like these (from 2018):
These worked, but were never great.
Thankfully, the 775 Connect (775 Connect - VEX Robotics) came along. After some initial skepticism, we’re converts. These are easy to solder on, protect the terminals, provide a solid connection to PowerPoles, and can even (with care) be desoldered and moved when you do burn out a motor. Now the connections look like this:
When controllers came with bare CAN wiring, we started using these JST RCY-series connectors, as we wanted a solid, solderless connection. These aren’t “latching” but have a positive detent engagement, and we had solid results with them. They’re a challenge to crimp & assemble properly, though several of our students became quite good at it.
We buy these from Digikey:
|Housing, female||JST SYR-02TV||455-2655-ND|
|Housing, male||JST SYP-02TV-1||455-2651-ND|
|Contacts for male housing||JST SYF-001T-P0.6(LF)(SN)||455-2652-1-ND|
|Contacts for female housing||JST SYM-001T-P0.6(N)||455-1909-1-ND|
Since controllers now often come with PWM-style connectors preinstalled, we tried using them in the 2020/2021 robot:
We have not had good results with these. They absolutely require clips, since without, connections are completely insecure. Unfortunately the clips are a pain to work with and do not secure the connection much better – a hard tug will pop the clip right off. And when students put them back together, it’s all too common to reverse the connection (yellow to green) which, of course, completely breaks the bus as well. We won’t be using these going forward.
We considered going back to the JST RCY style connections, but at @came20’s recommendation, we’re now trying these 2-pin connectors with a secure locking mechanism. They are roughly the same effort to crimp as the JST ones.
For SparkMax connections, to go with the above we’re purchasing the JST-PH 4-pin connector that mates with the SparkMax, and starting to make fully custom CAN cable assemblies. This has the nice advantage that we can make the leads the length we need, instead of making extender cables (with more points of potential failure). Again, the main challenge is making the precision crimps needed; the JST-PH contacts are quite tiny. Buy plenty of extra contacts to account for do-overs.
Digikey part numbers:
|Latching Housing, male||Molex 0050579402||WM2900-ND|
|Latching Housing, female||Molex 0701070001||WM2533-ND|
|Contacts for male housing||Molex 0016020086||WM2510CT-ND|
|Contacts for female housing||Molex 0016020107||WM2517CT-ND|
|4-pin JST-PH connector for SparkMax||JST PHR-4||455-1164-ND|
|Contacts for JST-PH connector||JST SPH-002T-P0.5L||455-2148-1-ND|
We generally minimize use of ferrules. They are occasionally useful on small wires but should never be used on the WAGO power connectors on the PDP (which are designed to “squish” wires for maximum surface contact). We sometimes use them on PCM solenoid connectors; here’s the other end of the pneumatics harness:
However, find that for 18ga Weidmuller connections like the compressor, they don’t engage well - the ferrules that fit the wires are too big to comfortably fit in the PCM connections.
The standard .1” pin connectors on the RoboRio pull out easily. Even though we generally don’t have a lot plugged into these, even keeping the RSL connected can be troublesome. After one too many times of having a disconnect, last year we bought the Swyft Robotics RoboRio JST board (JST Connector Boards – Swyft Robotics Shop) . So far, we’re pleased – the connections are much more secure with this, and the price was reasonable.
Whether using the bare Rio connectors or the Swyft board, unused connectors should be taped over, as seen above. Otherwise, the first time your mechanical team does a little drilling nearby, you may find yourself disassembling your Rio to extract the aluminum chips that are shorting out its power rails. Ask me how I know that…
The advantages of brushless motors are compelling. One change that has brought is that we’ve moved to mounting controllers as near as possible to motors, so that we seldom have to extend the encoder connections. This also makes for more flexible placement of the PDP, since it’s not surrounded by controllers any more. For example, here are our drive controllers, mounted to a plate directly atop the gearbox:
One concern with SparkMax’s is that if the CAN connector to a single controller gets unplugged, it breaks the whole CAN bus. We zip-tie the CAN wires to the power leads to prevent this, as can be seen above.
And here is a shooter and feed-roller motor controller, set into the side of our shooter assembly in a 3d-printed mount, keeping them just below the motors they control:
We hope this quick tour of 6328 wiring was useful - let us know if you have any questions or comments!
Do you use JSTs for sensor cables? What crimping tool do you use for those?
By sensor, I assume you mean the Neo encoder cables? So far we’ve not made our own (we used the premade Rev extension + joiner board in the one case - our intake - where we had to). But having made up the 4-pin CAN JST, I see no reason we couldn’t do the sensor cables as well.
Rev recommends the IWISS SN-2549 (Control Connections - SPARK MAX) for JST crimping. Use the narrow crimper at the tip of the tool for these, as they’re very short contacts. So far this has worked OK for us.
Where do you get your flexible electrical cables?
For the flexible welding cable, it’s pretty readily available on Amazon; we’re currently using this: https://www.amazon.com/gp/product/B019O1MANK
…but there are certainly other options.
For other wire, we’ve got a mix of PowerWerx (which is very good quality, but higher priced + costly to ship), Amazon-sourced (make sure what you’re ordering is pure copper, as there’s a lot of CCA listings), and locally-bought wire spools.
I’ve done a season of electrical, and the speed controller wires are fairly flexible. However, the battery cables are not, and we’ve never attempted to fabricate our own. We always used the ones from KOP or sourced from AndyMark. How did you put the battery clip on?
All the wiring changes look great! We used the JST RCY-series in 2017 but ran into a lot of quality control issues and problems ensuring the CAN cables were plugged in correctly. Since then, we have used locking JST SM connectors and they have been a god send for us. I’m not sure how they compare to the locking Molex, but I thought I would provide the recommendation if y’all wanted to stay on the JST line.
@Aaron_Li Crimping the SB50 connectors requires a hefty crimp tool; fortunately the same crimper works for both those and the 6awg ring terminals needed on the other end. We have a long handled crimper that produces decent crimps (and the students get a workout using it!) but I’ve considered getting a hydraulic style one.
You make a good point about battery cables. I think we may eventually start to use the flexible cable on battery harnesses too. In fact, AndyMark now sells a flexible version - am-4483. For the moment, though, we have a LOT of the standard battery harnesses from KOP, FIRST Choice, etc. so we’ll probably use those up first.
Here is a little message from the Game Design Team:
Team 6328’s Game Design Challenge team has been working very hard over the past few weeks and has reached a point where we can share our created game with the FRC community. Included in the post is the required documentation (game overview, notable field elements, expected robot actions), ELEMENT description, field images, CAD models of some of the field structures, and parts of what we plan to include in the supplementary information. We also plan to include in our submission a game video, additional supplementary information, multiple field images, and an entire CAD field. We would like to hear feedback and be able to clarify information present in the hopes of creating the best game possible. So here it is:
In MALWARE MAYHEM, two alliances of 3 robots each work to protect FIRST against a malware attack from the anti-STEM organization LAST (League Against Science & Technology) and ultimately save future FRC game files including those for the top-secret water game. Each alliance and their robots work towards collecting lines of CODE and deploying them in the INFECTED CORES in the CPU. Near the end of the match, robots race to share CODE into a shared cache with the opposite alliance, and at the end of the match robots collect firewalls and install them into the CPU.
During the 15 second autonomous period, robots must follow pre-programmed instructions. Alliances score points by:
- Moving from the initiation line
- Deploying lines of code into the infected cores of the CPU
- Deploying lines of code into the uninfected cores of the CPU
- During the 75 second tele-op period, drivers take control of their robots. Alliances score points by:
- Continuing to deploy code into the infected cores of the CPU
- Continuing to deploy code into the uninfected core of the CPU
- During the 30 second first endgame period, robots score points by:
- Continuing to deploy code into the infected cores of the CPU
- Continuing to deploy code into the uninfected core of the CPU
- Deploying 5 lines of code into the shared cache to achieve stage 1
- Deploying 10 lines of code into the shared cache to achieve stage 2
- Deploying 15 lines of code into the shared cache to achieve stage 3
- During the final 30 seconds of the match, robots score points by:
- Continuing to deploy code into the shared cache
- Installing firewalls into the CPU
- Hanging from installed firewalls
The alliance with the highest score at the end of the match wins.
AUTO - The first 15 seconds of the match where the robot moves by using code
CODE - An 18 inch long chain that is the main game piece, ELEMENT
CORE - One of 7 scoring are on each side of the CPU
CPU - The central scoring unit that divides the two halves of the field
DATA BUS - The tunnel under the CPU
DEPLOYMENT PERIOD - the last 30 second period following POSITIONING PERIOD
FIREWALL - A suitcase-shaped object with a handle
INFECTED CORE - Scoring areas on the CPU that are highlighted with LEDs
INITIATION LINE/DEFENSE LINE - The line X feet from the CPU
LAST - League Against Science & Technology
MALWARE MAYHEM - The name of Team 6328’s concept game
PLAYER STATION - the station where a human interacts with the game piece to give to the robot
POSITIONING PERIOD - The 30 second period following TELEOP
PROTECTED ZONES - Areas on the field in which defense is penalized
ROBOT - the mechanism used to complete the tasks
SECURITY CONTEXT - A trapezoidal platform which stores the FIREWALLS prior to deployment
SHARED CACHE - Scoring location for the Coopertition mission
SHARING CODE - This is used to allow the alliances to cooperate
TELEOP - The time after auto where players control the robot (2:15)
UNINFECTED CORE - Scoring areas on the CPU that are not highlighted with LEDs
Notable Field Elements:
Shared Cache: A scoring location on the opposite alliance’s driver station wall. The scoring location is a single window the same size as the windows on the CPU and is directly over the center of the alliance wall. CODE can only be scored during the POSITIONING PERIOD and DEPLOYMENT PERIOD periods, and teams will have to reach different scoring tiers to receive equal points for both alliances.
Security Context: A platform X feet high that houses 3 FIREWALL units: One directly in front, and two angled on either side. The Security Context is located in front of the alliance station walls of the same alliance color.
CPU: A large structure that separates the two halves of the field, consisting of seven CORES on each side and a central opening (DATA BUS) for interaction between alliances. A total of 5 goals span the upper level of the CPU, and there are an additional 2 goals on either end of the CPU near the edge of the field. Throughout the match, different CORES will be randomly highlighted with LEDs, marking them infected. The three high cores in the center have a slot below the scoring opening for installation of the FIREWALL. An additional scoring area for the FIREWALL is located on each side of the CPU near the edge of the field.
Player Stations: There are four player stations located in the four corners of the field. There are blue and red player stations on the blue alliance station wall and the same for the red alliance station wall, for a total of two per alliance. The player stations on the opposite side of the field of the alliance station have PROTECTED ZONES around them, while the stations on the same side do not.
Expected Robot Actions:
During the Autonomous Period, teams are tasked with moving off of the INITIATION LINE such that no part of their ROBOT is over the line. Teams may score in CORES, but they must collect the code through the PLAYER STATION.
During the 75 second Tele-Operated portion of the game, the team’s main task is to shoot lines of code into the CORES of the CPU. The primary locations that teams will be able to receive code is from the PLAYER STATION on their own side or on the opposite side of the field.
During the POSITIONING PERIOD, which spans the second-to-last 30 seconds of the match, teams may retrieve FIREWALLS from the SECURITY CONTEXT, and prepare for the DEPLOYMENT PERIOD. Teams may also race to the other end of the field and deposit CODE into the SHARED CACHE. However, any robot that passes through the DATA BUS and does not return by the end of the Positioning Period must remain on that side for the remainder of the match.
During the DEPLOYMENT PERIOD the final 30 seconds, teams are no longer allowed to pass through the DATA BUS. During this period, teams are expected to deploy FIREWALLS by inserting a FIREWALL into the CPU and pulling themselves completely off of the ground. Teams, if on the opposite alliance’s side, are expected to play defense on climbing robots, deploy code into the shared cache, and/or try to prevent their FIREWALL deployal. However, teams must be careful not to cross the DEFENSE LINE.
The ELEMENT in MALWARE MAYHEM is the main game pierce in our game. The ELEMENT represents lines of anti-malware code, and robots must deploy the code into the cores, infected cores, or the shared cache to earn points. The ELEMENT itself is a 18” plastic chain with 2” links. Each chain will have a magnetic component on one end, allowing it to be automatically scored as it passes through scoring locations. All scoring goals will have a magnetic detector that will detect any chain that is scored through that specific goal. The ELEMENT enters the field through the four player stations on the field. During auto, chains will not be located on the field, instead all chains will be either pre-loaded into the robot or collected from the player stations.
Initiation Line: At the start of each match, each team’s robot must start behind the auto line consisting of a long strip of white spanning the entire width of the field on their alliances side of the field. Once each robot of a teams alliance crosses the plane of this line, a ranking point is earned for the team. During the Endgame period of the match, this plane acts as a defense line, where, in the last 30 seconds of the match, robots of the opposite alliance are not allowed to cross this line so as to not interfere with gameplay (climbing).
Collection Line: This is the line that spans the width of the field at the end of the no-defense zones on each side of the field.
Collection Zone: This is the area of the field that spans from the COLLECTION LINE to the alliance wall. While in this zone, robots cannot attempt to deploy CODE. A robot must move completely outside of the zone to be able to deploy CODE
Scoring Zone: During TELEOP and the POSITIONING PERIOD, this is the area of the field that is in between the two INITIATION LINEs on either side of the field. During the DEPLOYMENT PERIOD, this zone is in between the COLLECTION LINE, and the INITIATION LINE on either side of the field.
Retrieval Zone: These zones are the marked areas on the field surrounding the human player station on the opposite side of an alliance’s driver stations. At all times during the match, defense is not permitted on robots that are in these zones.
Climbing Zone: This zone becomes active only during the DEPLOYMENT PERIOD. This is the area of the field in between the two INITIATION LINEs on either side of the field. During the DEPLOYMENT PERIOD, no defense is permitted on a robot in this zone.
SHARED CACHE Stages:
Points from shooting in the SHARED CACHE come in 3 stages. This means that each alliance in a match will only receive points after a certain number of lines of CODE has been deployed into the SHARED CACHE by both alliances. Once both alliances have deployed 5 lines of CODE, stage 1 is achieved. Once both alliances have deployed 10 lines of CODE, stage 2 is achieved. Once both alliances have deployed 15 lines of CODE, Stage 3 is achieved.
Before the due date we plan to have a complete game video, more supplementary information, including game specific penalties, robot construction rules (starting height, endgame height, bumpers, weight, etc.), even more CAD models and an entire field, role of the human player, and more game piece details. Also, we are planning to create some modified FIRST logos.
Feel free to ask any clarification questions and thanks for helping out!
What did we say about virus games?
Edit: joke guys come on
This is a different type of virus…
I assume this is stage 1, stage 2, and stage 3
I love the League against Science and Technology!
" Deploying 5 lines of code into the shared cache to achieve stage 1"
" Continuing to deploy code into the infected cores of the CPU"
If I had one suggestion to give, it would be to rename some of these actions. That’s a mouthful! You need something short and sweet enough that strategy teams, drivers, coaches etc can make themselves clear quickly. Maybe use acronyms for LOC (lines of code) and ICs/UCs (infected cores)?
Oh thank you, I am going off of what the game design team is saying and I would assume it’s that, but I will get back to this ASAP after discussing it with them.
did you guys find that the acceleration wheels were necessary? My teams new, and are trying to talk ourselves out of the additional motors…