FRC 6328 Mechanical Advantage 2020-2021 Build Thread

Week 3: Insert Witty, Robot-Themed Title Here

I know I know, the title is cliché but it’s been a hectic third week of build/work season and I’m running out of ideas ALREADY. I probably just need some sleep, but oH WeLL.

In the shop, unfortunately, there is still only 25% building capacity following COVID precautions so there can only be about four people in the shop at any one time and one person per every other room.

Game Design:

1/31/2021 - The Game Design Challenge team discussed changes to the auto/tele-open/endgame structure for our game, a cooperation mission between the teams, which will include some sort of addition scoring location on the opposite side of each alliance’s driver stations, and how climbs will affect endgame and robot interactions during the time. We will be continuing with students creating basic sketches of the field for this week and starting rough drafts of required documentation. -Jonathan M.

Basic Field Map Draft:

2/3/2021 - The Game Design Challenge team finalized the general endgame tasks, but we still need to figure out the specifics of how the climbing mechanism will work and robot interactions during the endgame. We also divided the match time into separate auto/tele-op/endgame time frames for the match. The team broke into small groups to discuss, in more depth, the physical dimensions of the game elements, which included initial CAD sketches with the help of the mechanical team, who also provided their opinions on the game and the design of the game elements and pieces. The other team went further into developing our theme by giving names to game pieces and elements that fit the overarching theme. We decided on where we want the cooperation task between the teams to be located, but still, need to go into further specifics.
We are planning to continue developing the field sketch in CAD, continue to develop the theme, and start to focus on game balancing (points, penalties, etc.). -Jonathan M.

Sketch-Up of Main Scoring Location:

Awards Team:

1/31/2021 - Quick summary from tonight:

  • Katie reviewed executive summary questions and edited them to make sure same info isn’t presented twice, etc. Maddie and Michelle will review this week to get down to the right number of characters.
  • Aryan and Anne have a draft of WF nomination ready for review.
  • For 2/7, will have a rough draft of CA essay ready for review.
  • Once essay is in review process, will start outlining CA interview/presentation.
  • Need to start focus at the same time on prepping tech and game design teams for doing virtual interviews/presentations.

Mechanical/Shop Work:

2/2/2021 - Here are some pictures of our first blue nitrile wheel! The powder coat chipped a little so we may need to touch up. Tomorrow we’ll be done with the rest, and we’ll try rivets on the remaining two so we have a way to compare and possibly save some effort in future years. Thanks to Maddie, AJ, Shirish, and Jack for doing all the work and making this go so smoothly! -Cameron E.

Definitely didn’t poorly edit out some of the paint chips in these photos with a mouse to make it look prettier… wh- why would I do that? PFFT, definitely NOT ME though.

2/3/2021 - Powder coated. - Luke

2/3/2021 - All 6 wheels ready to go! Spacers were a bit tight so they are being reprinted, some students are planning to come in tomorrow afternoon to get them installed before programming tests them in the evening.

2/4/2021 - I helped replace all the wheels on the drive today with Lizzy, Shirish, Maddie, and Jack. - Alisha

2/4/2021 - So on arrival tonight the compressor was not remounted, and when we went to do that, we found it doesn’t quite fit between the wheels any more; the new ones are notably bigger, roughly 6 1/4" instead of 5 3/4". :slightly_frowning_face: - Brett Bonner


2/4/2021 - For Cad and Design, we have been working on designing a new sheet-metal robot cart with some students to allow them to gain knowledge and experience for next year. We only started meeting with these four sophomores last Monday (2/1/2021) and are at the stage where these students are observing the process first and will begin working on their design in the upcoming week or two. - Me (Hallie)

2/4/2021 - Also, the intake is undergoing a bit of a redraw because we still need to add a spot for the motor (probably a 775 Pro for more power) and gearbox. Overall the basics of the design will stay the same though but more will be added to it. I will try to post some more pictures of it by the middle of next week (if procrastination doesn’t get the best of me first lol). - Me (Hallie)


2/3/2021 - In order to ensure we can accurately hit the target from all of the zones, the software team did a ton of testing to characterize the shooter behavior at different flywheel speeds. We started at our standard 6000 RPM from each zone, and established that (yes) we can mostly hit the outer port but (no) we can’t reliably hit the inner port. - Jonah B.

2/3/2021 - At each hood position, we then manually measured the optimal flywheel speed for a variety of distances through trial and error. We can plot those on a graph and use polynomial regression to fit a quadratic function to each one (see below). The x-axis is the distance from the center of the robot to the target in inches and the y axis is flywheel speed in RPM. Purple is the wall shot, red is the initiation line, and blue is the trench. These data points represent the maximum range where we could reliably hit the target in each hood position. A few notes- There’s a fairly wide overlap in the ranges for line and trench, so we’ll probably put an arbitrary cutoff between 180-200 inches when selecting which hood position to use. On the opposite side, the wall shot data was unexpected. We can fairly reliably hit the inner port from several feet back using low RPMs (even if that isn’t incredibly useful). Unfortunately, it’s extremely difficult to make shots between about 90 inches and 120 inches. That’s not somewhere we’re likely to shoot from, but worth noting. - Jonah B.


Flywheel Graphing:

2/3/2021 - After creating these models, we did a quick test by shooting from a previously untested distance in the line hood position, using the calculated RPM. The ball bounced out, but the freeze frame says it all. - Jonah B.


2/4/2021 - For software work tonight we took it out as we were just driving, but we’ll need a solution before we can shoot anything. Short term, it could mount in the right-hand climber space - until we decide to put a climber back on. It could still go between the wheels if supported about 1" below the bottom of frame rails since the mounting ears are the widest part, but that sort of bottom protrusion probably isn’t ideal (pics below). Also, we’re having some clearance issues between the right-hand pneumatics tank & the hopper which I don’t remember having before, or maybe just hadn’t noticed - may need another custom low-profile clip mount as we have on the left, or something similar. (The right-hand tank has a standard mount, which is taller.) - Brett Bonner

Challenge Updates:

This section is just primarily for challenge videos but I may post some photos in the future.

Slalom Path - Autonav (Run 3):

Slalom Path - Autonav (Run 4):

Slalom Path - Autonav (Run 5):

Barrel Racing - Autonav (Run 1):

Robot motor go BRRRRRRRRR

Quote of the Dave:



Thanks my friend! We had a great time working with y’all! Hopefully next time we can get those last two wins!


You have NO IDEA how much we wanted that!


absolutely dying at this Hallie, look at this graph will never not be funny :rofl:


Bahahha facts though, iconic meme moment


Hey everyone,
The previous few posts have included some information about what the 6328 software team has been working on, but we thought it would be worth going into a little more detail about our adventures with motion profiling.

Our motion profiling system is built using the standard functionality built into WPILib. We wrote a custom command which wraps the normal RamseteCommand. This gives us an easier API for setting up the profiles and means we don’t have to define all of the constraints for each one; There’s only one configuration per robot.

For each path, we wrap the motion profiling command in a command group. We do this for a couple of reasons - first, breaking each path into a separate file makes them easier to manage. Also, we can easily add in functionality before and after the profile. Before running, we set the odometry position using our coordinate system (with the origin in the upper right of the field near A11). Because we don’t care about the ending position, we set the ending velocity of the profile as high as possible and chain a command to brake after - the robot can stop quite quickly so we don’t hit a wall. The odometry can’t track accurately through that kind of skidding, but exact positioning doesn’t matter at the end of the profile.


When iterating quickly through versions of the trajectories, testing on the robot can get quite cumbersome. We’ve been using a path visualization tool put together by @came20 . Here’s some more information on that system from him:

I wrote this tool a couple of years ago as a student on FRC Team 401. We were getting into advanced trajectory following (this was before spline trajectories and the Ramsete controller were part of WPILib) using Team 254’s code as a reference. I needed a way to quickly visually examine trajectories before running them on a robot to ensure they had no malformed sections (such as wheels reversing due to tight turns, forgetting to set a trajectory as reversed, etc.), check that constraints were being applied correctly, and verify waypoint geometry.

The tool generates the trajectory using WPILib’s trajectory generator, and then plots the resulting path on the screen. It then uses inverse kinematics to draw the paths of the left and right wheels, and colors these paths on a gradient based on the maximum speed throughout the path. This “heatmap” visualization makes it very clear to see which parts of the path are acceleration or deceleration, and to check that centripetal and region constraints are being applied correctly. The tool also provides the ability to “simulate” the path by drawing a “robot” (black square) which traverses the path at real-time speed. This isn’t a true simulation in that it does not account for any sort of physics, instead purely drawing what the trajectory is commanding the robot to do. This is useful for getting a visual sense of how the robot should behave, and identifying areas where the robot appears to be doing something physically impossible. Along with this real-time display, some statistics are drawn in the upper left corner about current pose and timestamp. The tool uses Swing (built in Java GUI API) to draw the graphics, and it was built very rapidly, so not much work was put into making it pretty.

The code for the visualizer can be found in my “FRCKit” library, a work in progress to bring tools like this as well as simulation and other utility libraries to more FRC teams. The project is in no form release-ready or even well organized yet, but nevertheless the source code can be found here

As an example, here’s a video from the visualizer of a trajectory we tried for the barrel racing path:

Galactic Search

Our plan for Galactic Search is to define the four possible profiles ahead of time and select one to follow when the run starts using vision (more details on that in the coming weeks). Our work thus far has been to start defining each of those profiles. One of the questions we had to answer was whether to start each profile from the same place (which simplifies the vision pipeline) or try to optimize each starting location (potentially saving valuable time). As a proof of concept, we visualized two trajectories for each path - one with a center starting position and another with an optimized off-center starting position. We tested using a cubic spline with waypoints on each power cell, and tuned the starting directions of each. The results of our testing are below. There are also videos included, where left is off-center and right is centered.

Given the short length of these profiles, our conclusion is that saving even a fraction of a second is worth the extra complexity. Also note that the center starting positions are still tuned to different angles, so if we used a single starting position (including direction) the discrepancy would be even greater.

Circle Profiles

For several of the paths (slalom and barrel racing) the robot needs to maneuver in a circle around the waypoints. For our initial testing, we tried to define waypoints such that they formed a continuous curve:


That isn’t terrible, but it’s also clearly not the optimal route. We’ve been doing some work to instead define perfectly circular profiles. Unfortunately, WPILib’s trajectory generator doesn’t support something like this on its own, so we needed to give it a little (a lot) of help. All of this functionality is part of our motion profiling command I linked previously if you’re interested in the details. The path itself is defined by hundreds of waypoints spaced a tenth of an inch apart in a circle. That forms a trajectory which looks something like this:

Unfortunately, the red color coding indicates that both sides are moving at the same maximum velocity, which a) doesn’t satisfy the centripetal acceleration constraint we defined and b) isn’t how to drive in a circle. On a real robot, you get something like this ( It tries to correct the position, but goes way off course. The issue is that the trajectory generator thinks the curvature of this section is 0 (it’s completely straight), meaning it doesn’t properly apply constraints or compute wheel speeds. Since we know the properties of this circle, our solution was to manually adjust the curvature of each point after the trajectory was generated, which results in this:

That’s a big improvement, but there are still some issues. First of all, the curvature changes abruptly going into the circle which means the wheels have to accelerate very quickly. We actually found that this wasn’t a major issue in testing, and the drivetrain seems to behave reasonably. However, the larger issue is that our constraints are still not being obeyed so we’re exceeding the maximum velocity and centripetal acceleration (those are all still calculated using a curvature of 0). The solution? Apply a custom constraint within the circle. To provide maximum velocities and accelerations, this constraint passes calls through to all of the standard constraints that we apply to the whole path. However, it runs the calculations using the corrected curvature. The constraint also determines the maximum chassis velocity which will prevent the outer wheels exceeding their maximum velocity. Once the curvature is fixed after generation, all of the constraints are obeyed properly:

Below are some examples of running these profiles on the robot. This is the first time we ran with proper constraints- the circle looks good but the positioning is a little off. We were able to address that with further tuning.

Here’s another example on the barrel racing path:

We’ll keep everyone updated as we make more improvements in all of these areas, and we’re happy to answer any questions.


Programming team shared a couple videos, just wanted to post them quick!

Super excited about this, hoping we’ll see an 8 ball and maybe more! :thinking:


As much fun as it would be to think that this just worked the first time, to be fair we should also share the blooper reel! A lot of the useful learning happens when you’re trying to figure out why things aren’t working they way you want them to. (Which I know you know!)


Thanks for sharing your experience and the impressive autonomous code! I do have a question about class CirclePath. Can you explain a little more about two parameters in the constructor: startingRotation and endingRotation. The comment in the code does not help much. I have some difficulty to determine what value should be used in barrel and slalom racing if CirclePath is used. I see you are using 0 and -180 for the first circle of barrel path, -160 and 160 for the circle in slalom path.


Sorry for the confusion on that. As is perhaps obvious, we haven’t spent much time cleaning up this code. The starting and ending rotation parameters set the position along the circumference of the circle to place the start and end points. Those angles are perpendicular to the robot’s direction of travel. A starting rotation of 0° would place the first point directly above the center while 90° would be directly to the left. Here’s a diagram of our configuration for the slalom path, traveling counterclockwise:

The angle of the robot is determined based on the direction of the path. Note that the initial pose for the above circle would be at -70° instead of -160°. Also, this method means switching from clockwise to counterclockwise fundamentally changes the trajectory. The two directions look like this…


…and NOT this.


Hopefully this helps, and let me know if you have any more questions.


Thanks for detail explanation. It make perfect sense now. For barrel path, the robot is in circle path for half of the circle (e.g. 0 to -180), correct? Can you also explain how you integrate FRCkit into your project?


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 0.0.30.

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.

Leadership Training

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
  • Communication
  • 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:

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:

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

Main Power

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!

Solenoid Connections

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:

CAN Wiring

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:

Part P/N Digikey P/N
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:

Part P/N Digikey P/N
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… :blush:

Controller Mounting

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?

1 Like

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?

1 Like