I would also differentiate between single and double solenoids just so teams with only single solenoids and not a lot of pneumatic experience don’t freak out.
The red line +5V on a PWM wire will also be the center wire. Neat feature so if you plug PWMs in backwards you will not fry anyting.
Thanks for the feedback! Looks like my PWM knowledge isn’t quite up-to-par (in my defense, our team went all in with CAN this year, and I can’t say we’ve ever looked back).
Here’s an updated snapshot:
(Chief Delphi doesn’t like high-quality pictures, apparently)
Also, if anyone finds this to be a useful resource (just like how the 2015 one that Frank Merrick auctioned off a couple weeks ago was really helpful for our team in teaching new members electronics), here’s a high-res, printer-friendly pdf.
1 Like
I might suggest adding wires for the outputs of the speed controllers (with their associated colors and polarity) and noting that they go to the motors (you might have to reverse the PWM speed controllers to do this).
You could also probably move some of the items on the right side over a bit to get more room if you’re trying to maintain a particular size. You could also probably shrink the compressor graphic.
Also, most wiring diagrams indicate wire cross points with indicators like these that you might want to consider adding:
Gauge sizes are also nice to have.
Looks like you have wire size reflected in the diagram just based on the thickness of the wire, but maybe have a key or annotations?
That’s one way, and it’s arguably easier to read, but it’s a hell of a lot of work. There’s another popular style which shows crosses like the OP did, and interconnects with a dot. I prefer that style personally.
edit: and there’s only one spot on your diagram you’d use a dot - at the RSL. Maybe at the POE injector (but that’s weirder)
Love that you’re doing this, we haven’t had a properly updated system visual since 2015, looking great so far!
One thing to note though is the PWM cable on the SPARK is flipped, ground goes towards the outside of the controller 
https://images-na.ssl-images-amazon.com/images/I/51GXnDV605L.jpg
This is a cool resource.
I would suggest making some of the symbols (especially the RSL, servo, compressor) for the components smaller to give you more “space” on the drawing. They do not have to be to the same scale to communicate how they are connected.
Standard practice is for wire sizes and colours to be defined in a document separate from the schematic. The schematic should contain a reference to the relevant Game Manual for the wire sizes and colours so that they are only defined in one document. This avoids the problem of conflicts between documents.
The most unambiguous practice for schematics is to always indicate junctions with a T-intersection. Thus, wires crossing (like a +) always indicates no connection. With this methodology, the dots are completely optional. One reason for this comes from when reproduction methods were more “low-fi” i.e. blue-prints and photostat machines (early form of photocopier). These older reproduction methods produced fuzzier images and after one or two generations of copies, details such as the dots would become indistinct and cause confusion. The schematic that Brendan attached is drawn using this methodology. If I am not mistaken, there is an old Mil-Spec that required schematics to be drawn this way.
Looks great but a couple of nit picks.
I would not consider the nominal 12v battery to be “high voltage” which I associate with dangerous voltages. Also since the robot frames are isolated I wouldn’t call the corresponding black lead ground. I’d suggest the use of the common terms B+ and B- which is what you’ll actually find on some of the motor controllers.
For the same reason I wouldn’t call the black wire in a PWM ground but instead use either B- or Signal Return because it allows the signal current to return to the source.
It might make sense to change the label “Victor SP” to “Victor SP/SPX/Talon SRX” in the PWM section. Many teams don’t realize SPX/SRX supports PWM and CAN-bus (auto detects on the same wires).
I would Put the output lines on the motor controllers. After all, that is the point. --looking good
But why would you ever use them this way on an FRC robot?? Since the SRX came out, the only reason we’ve used PWM is because we were able to use controllers we already had, or we’re controlling it with an Arduino; in both cases we’ve used PWM-only controllers, which are significantly less expensive. Just because you can doesn’t mean that you should.
And to OP, thanks thanks for this! Our main controls guy will be a senior this year, and we really need to train his replacement; this will be a great help.
I agree, and I like CAN bus too. I’m sure there are other CAN-vs-PWM and TalonSRX-versus-whatever CD threads that cover the reasons.
But ultimately it is the team’s choice, and I thought the wiring diagram was meant to show all the options.
Also Victor SP is not available for purchase anymore, because it has been replaced by Victor SPX (lower price + CAN/PWM). It came off as strange that the SP was on there, but not mention SPX for PWM.
BTW, kudos to the OP - great work.
Since you put a mechanical switch on the diagram, for bonus points you could add a wiring diagram for an NPN switch (infrared, ultrasonic, inductive etc.) like this one. They are trickier because you they typically run on 12V (so you need to get power from the VRM, not the Rio) and the switching state may not match the threshold of the Rio’s digital inputs so it might be easier to wire it to the Rio’s analog input. If it sounds like I don’t fully know what I’m talking about, it’s true - so a wiring diagram would be helpful Someone with more electrical expertise than me can put together a sketch.
Yes, showing how to connect these NPN-output devices would be helpful.
The RoboRio’s switching thresholds should not be a problem with the NPN-output devices since the output voltages should be just below the 12 V supply when in the Hi state and very close to zero V when in the Lo state.
The RoboRio Spec Sheet states that Analogue Inputs have a range of 0~5 V and are protected for ± 16V. While the Analogue Inputs will survive being connected to +12 V, it is not good practice. It would be better to use a resistive divider to drop the Hi level to below 5 V so that the protection devices are not active for long periods of time. It would then not matter whether it is connected to one of the Analogue Inputs or one of the Digital Inputs.
The Digital Inputs are “compatible” with 5 V inputs and have 40 KOhm pullup resistors connected to the internal 3.3 V supply. I have never found any references to protection devices on the DIO’s. It is not clear if they are guaranteed to survive being connected to anything higher than 5~6 V.
Isn’t that contrary to what you said here? https://www.chiefdelphi.com/forums/showpost.php?p=1730101&postcount=7
Good catch!
There really needs to be two answers. My answer above assumes that the output is driven to 0V or the sensor supply voltage. In the old thread, the device was only driven to 0V and relied on an external pullup resistor to provide the Hi level, hence the resistor to the 5 V supply. I just noticed that the datasheet that Brendan linked to would indicate it is like the one in the old thread if one reads between the lines for long enough.
There’s a major rewrite of docs.wpilib.org coming out this season, and I really like this hardware overview image, it’s very readable.
A page that it might work well on is linked below directly in github - would you be willing to add it?
To meet style guide, you’ll probably want to take the team logo off & just add a citation/image credit back to your team website at the bottom.
If you want to be an overachiever, it would be awesome to spin off a second, simpler version that included only the components in the “Getting Started” guide for the top of the page, and put the advanced layout published in this thread at the bottom of the page.
I have an open pull request to add a similar diagram by @stefenacepcion, which (I think) was influenced by the diagram shown in this thread. I think the two diagrams are very similar, except that @stefenacepcion’s diagram has wire sizes and fewer wire crossings. I have also been using a style similar to @SentientBacon and @stefenacepcion to make other diagrams in the PR.
1 Like
This is a helpful diagram for newer teams or teams that have to go over their wiring system.