Electronics organization

This season my team had a small chassis relative to those we have built in the past. With this came a bit of a problem regarding electronics placement and organization. We designed in wire channels in box tubing and made use of braided wire sleeving from Andymark, but we still ran into issues, as we had 14 sparks and not much room. This lead to a variety of problems with reparability and overall reliability. We wonder what some ways of situating electronics in a uniform reliable way look like. could anyone share ideas?

Mounting electronics on the bottom and sides of the robot (Dedicated electrical panels) helps a lot so you don’t have to have everything on the bellypan. Having motors with integrated motor controllers (krakens, falcons, neo vortex don’t use rev) also helps out a ton.

10 Likes

why do you think rev shouldn’t be used? We have had good success running neos in the past years, although I definitely prefer krakens over vortexes.

Rev products (with the exception of my beloved PDH), are often unreliable and very code-unfriendly. Ask pretty much any FRC programmer and they’ll tell you how much they hate rev.

7 Likes

I think certain products (like the NEO 550) are irreplaceable in some applications, and are (usually) more available as well. Vortexes aren’t fully substituable either, through-bore can be nice.

Also, I commend REV for shifting to WAGO connectors, it makes life SO much easier, and I wish competitors would follow.

1 Like

That seems way overblown. We’ve had a great amount of success with REV products (Spark Max, Flex, etc). Coding isn’t that challenging and the features that get most complaints are ones that are for simulation which you can make your own judgement, but doesn’t keep teams from building functional robot code. Some issues that we didn’t experience, but some others did, have been mostly fixed.

7 Likes

A number of people will say the same thing about VEX stuff. A somewhat smaller number will say the same about the Kraken. And by the way, some versions of the PDH have been somewhat unreliable in some ways.

“If you can’t say something nice, don’t say anything at all” is some really good advice here.

our team might be different then, our programming team enjoys our use of rev products. For mech/design during prototyping, the spark flex also became very useful, allowing us to easily mount hex shaft to it and run through the REV client. I believe we are planning on using krakens when we invest in swerve, although the rest of our robot will likely stay REV

5 Likes

I’d wager there are more than a few teams that would whole-heartedly disagree with you, and rightly so. REV equipment I’ve found to be MUCH better quality than comparable items…

OP, ignore this ‘recommendation’ and use what you like. There are a myriad of ways to package electronics in small spaces, and if you search around CD, you’ll find many quality examples of dense, serviceable layouts that are very creative.

5 Likes

While I do agree REV has good hardware and quality control (usually, ignoring some early rushed vortexes), I would argue, especially in the scope of modern FRC there are certain trade offs with REV software-side that I wouldn’t be willing to sacrifice.

While I can’t speak for others, our team has had a) multiple issues with SPARK Maxes, being exposed motor controllers, incurring damage over the season, although one could argue it is more up to negligence in the team. However, b) we’ve had bad experience with their software and firmware, given that many of the built in features such as Smart Motion are fundamentally flawed and usually unusable.

In specific vulnerabilities include the fact that REV Motors seemingly don’t apply their configurations and burn flash sometimes, resulting in improperly inverted motors for example.

On the other hand, our experience with CTRE has been just short of wonderful, with little CAN Loop issues or electrical issues, and the benefits from CANivore which are seen through implementation on the drivetrain saves tons of headaches. In addition, CTRE’s new Phoenix 6 software suite gives more control over their hardware.

That aside, REV Vortexes are still powerful motors, and if a team chooses to use them it is for sure not crippling or season-ending, (ex. 4481), but if OP would want to invest in new motors with integrated controllers, I would 100% recommend the Kraken X60 over NEO Vortexes.

9 Likes

Bumping this up too. There have been several times throughout the season where broken REV firmware updates for the NEO Vortex were pushed and have cost our team unnecessary stress and time. Big props to REV for doing their best to mitigate these issues relatively quickly throughout the season, but I can’t imagine how it would feel if we were one of the teams competing in early competition season and having to deal with that during matches.

6 Likes

I’m sure many teams use REV motors with no problems at all, but for some of us it can feel like we’re constantly getting tripped up by them. It happens enough that I know multiple highly successful teams that have all but sworn them off. After this season, we’re at that point too.

Aside from the ubiquitous story of a succession of NEOs and SPARK MAXes randomly burning up because one or the other of them might have somehow been slightly mistreated in the past, we fought throughout this season with motors randomly inverting even though we could see on the REV Hardware Client that their inversion states were not incorrect when the improper behavior occurred. That was one of the most infuriating, demoralizing gremlins I’ve ever dealt with because it felt like there was a grenade in our robot. Every match we were just hoping it wouldn’t go off—there would be no warning because every power cycle was a dice roll, so it wasn’t predictable from pre-match checks. The closest thing to an answer that we got was that it may have been corrected in a REVLib update. Our season ended too soon to know whether this solved it permanently.

There’s also the matter of being able to generate a ground short to the frame with a NEO 550 that I shared recently.

I want to love the REV motors as much as I do their other electronics and mechanical components, but I can’t begrudge anyone who says they’re not worth the trouble anymore.

7 Likes

As an FRC programmer, I second this notion. You’d think they didn’t know what documentation even is…

1 Like

I have used Rev motors and CTRE cancoders. Pretty much everything in code, especially configuration, is way easier and makes more sense with the Rev stuff.

This is annoying. However, we at least have never seen it happen except for immediately after deploying code, which might mean it’s somehow related to how the robot code starts/stops.

To OP’s original question: I don’t know a systematic way to optimize electrical layout. It’s forever a series of trade-offs since robot packaging changes so much year-to-year, but here is what I’m looking for:

  • Is the main battery cable length reasonable?
  • Is the main breaker somewhere reasonably protected but accessible?
  • Are circuit wire lengths reasonable, especially on high-load applications (and double-especially drivetrain)?
  • Can we get tools into the places we need them? (Less of a concern with PDH, but sometimes you’ll need to get something in to actuate Weidmuller connectors or snip a zip tie.
  • Is the radio high and on the outside of the robot?

We haven’t had to mount things upside-down yet, but never say never.

As for the REV discussion, I don’t have particular beef with them. Yes, it sounds like the way easier answer if you’re running SDS is to go all-CTRE. Yes, we’ve run into a few smaller quality issues over the years–but that tends to happen from just about every vendor. No, I don’t love the whole “smoke a NEO and you probably cooked the SPARK MAX too” thing. But a lot of it has been very easy to work with in less sophisticated applications (and boy howdy, are we less sophisticated) and the NEO 550 is a cheat code for smaller and cheaper mechanisms with good punch to them. We take the good with the bad and make the best move for us.

1 Like

In the application of a FIRST robot I am not a huge fan of wire sleeving. It is needed in some areas where chaffing will happen but IMO it’s best not to sleeve every single wire.

It’d be helpful to know what types of issues you ran into but I will give some recommendations on what we have historically done to wire out robots. We have been very happy with the reliability and never had any major wiring issues.

Quality Wire

Stiff stranded wire or solid core wire will never be your friend in a FIRST Robot. Get good quality flexible stranded wire.

Wire Termination

THIS MUST BE DONE CORRECTLY. Getting good quality crimps and the crimper designed for those crimps is critical.

We like to use the Anderson Power Poles for all motor power wires. AndyMark, McMaster, Digikey, Jameco are all good sources to get the crimps and housings. (Make sure to NOT get the crimps on a strip from Digikey unless you have lots of spare time on your hands to separate them all)

Another advantage to Power Poles is the ability to zip tie them after connecting to the motor this will insure they don’t come unplugged.

For smaller signal wires we do a couple different things. This past year we terminated new locking Molex SL connectors on all our CAN devices. The other option which we have done in the past is crimp a ferrule on the end of smaller wire and use WAGO 221 lever nuts.

Here is the ferrule kit we have:
https://a.co/d/1UgrU5y

These ferrules are preferred to make the effective diameter of the wire larger and more suited for being in the middle of the WAGO 221 range. It is also our preferred method to make the end of a wire solid compared to tinning the end with solder as this anneals the copper and makes it more brittle in the heated area.

Rio Wires
Get the WAGO Rio power connector from AndyMark. The wire clamp screws on the provided connector love to loosen themselves up and cause problems.

Hot glue all PWM, DIO, etc. into the Rio. I wish the Rio offered locking connectors.

Avoid barrel jacks. We use PoE power for our radio.

For our external network switch we use we have taken it out of the housing. Removed the barrel jack and soldered the power wires directly to the PCB traces. Then loop some wire inside the case hot glue it to the PCB and strain relief the wire. This will avoid the issues with creating a weak spot in wire after soldering it.

Big Wires 6 AWG and Up

Getting a good crimp on the compression crimps is important. This crimper has done great for us and I’d recommend getting one if you do your own large wire crimps. Also does the SB50 and up Anderson crimps.

https://a.co/d/fIZpJnQ

Inspect each crimp making sure the wire is fully crimped. After termination really pull on the wires. Like a lot I know I’d rather have it fail in my hands then be some weird intermittent issue later.

Planning and Wire Routes

Having a wiring plan is important. Send a electronics representative to CAD/Design meetings. Using vertical space is huge.

We are not a fan of putting the PDH/PDP upside down and like having the Rio on a flat central location to aid programming and the use of the Gyro. So those are the 2 things we have Design really focus on packaging.

For routing wires we used these (DigiKey Part Number 1436-1961-ND) and zip ties. We try to keep all signal wire bundled together and all power wire bundled together. Not running in line where possible and crossing perpendicular where feasible to help reduce the chance of interference.

1 Like

Using motors with integrated controllers on them reduces a ton of space needed. Otherwise, we have usually mounted sparks to the sides of 2x1 to reduce the amount of bellypan space used. We also try to use as few connectors as possible and to have as little slack in static parts as possible. This should reduce the pain of trying to follow a wire.

We also got adhesive cable clips off amazon which we stick around the bot and they help to organize the wires.

If we need to extend a wire, we solder the wires (even power wires) as it takes up less space and reduces error. Our CAN Bus is entirely soldered together.

When we have wires leave our bellypan, we encase them in a cable sleeve. We have two types, a bigger black one for power wires, and a thinner one with a blue trace for CAN wires. This helps to protect the wires and keep them organized, especially when on a moving part.

Some things you could do while planning/making your electrical board

Think about where to put your main electrical board. Most just use a belly pan to place components like power distribution or roboRIO, but in the case of a smaller chassis, for example, this can become quite cramped. This is where you turn to alternative electrical board placements. Components could be placed vertically under the chassis of the robot or stacked on multiple layers to save space. It all depends on your robot’s design and what’s ideal.

When looking at wiring and placements of other components, some things can help clean up your board. by measuring out your wires to your required length, they will be much easier to manage than if the wire was too long. Zip ties and zip tie pads help with managing wires and wire shroud can help when multiple wires are run together. Another thing that can help is labeling wires. When maintaining wires, labeling wires can help you easily tell where something goes without having to search. Components like motor controllers can be placed directly on the robot close to where the motors are. All the motor controllers don’t need to be on the main electrical board and spreading them out could help with space issues.

it’s due to blocking can calls which means that it will happen literally every time burn flash a config. Last year, I wrote a wrapper off of 3005 2022 and 1018 2023 code and I still found it easier to just bite the bullet and go ctre this year.

1 Like