FRC parts for review

I’m helping fix up some parts for the FRC robot folks to get them included in core parts. I’m intending on posting the fixed up parts here (as being easier than on github) so the original author can review them, but any of you are welcome to comment as well. The original discussion is here on github:

Unrelated to this part, but of interest: I am currently playing with making my own shaft encoders (the AMT103 is around $35 Can on digikey). I first used the Honeywell HOA0901-011 which was about $15 at digikey, but is now obsolete and $20 from the single source on ebay. Then I found the “Velocimetry Motor 334 line AB phase Encoder” on Ebay for $2.50 ea (unfortunately I bough all that were available at this price, but there are still some in the $3.50 range, still cheap compared to the alternatives). This is a small motor (low torque) with a 2mm shaft, a 334 line optical disk that can be removed (with difficulty!) from the motor shaft and a sensor like the Honeywell part, with active drive and I suspect comparitors on chip on a flimsy pcb that is easy to detach from the motors. This is worth it just for the optical part (which has no part number unfortunately), the motor and encoder disk are a bonus! I’ll probably produce a small board to hold the sensors (I have 3 so far where I destroyed the original board trying to put wires on it :slight_smile: .) If you want cheap shaft encoders this is a good bet!

That said here is a copy of the first part that has been done, the AMT103 encoder part (in three forms, the original part, the probable final part and an alternative schematic version):

original part

AMT103-orig.fzpz (5.5 KB)

likely part

edit (30 july 2019)

I have replaced this part with one that has the label field changed from enc to cui-enc because with both encoders labeled enc Fritzing creates two copies of enc1 which refer to different parts which is not correct (but will take a code change to fix). This is a simple workaround for this case.

AMT103.fzpz (7.5 KB)

alternate schematic

AMT103-alt-sch.fzpz (6.0 KB)

all three have different moduleIds so you can load all three at the same time if you like. To make things easy without having to download anything, png images of a test sketch using all three parts:

fzp file:

Mostly ok, added reference file and fritzing version to the module line. Removed some unneeded properties and changed the varient from 6 to 1 (as this is the first version of this part). Added a description of the part from the data sheet so it will show up in inspector, added descriptions to each of the pin names so the data comes up when you hover over a pin in any view. Add a url for the part datasheet, added a 1 (for the varient number) to each of the file names (and renamed the files to match after I found a new Fritzing bug when I didn’t rename them the first time :slight_smile: . Removed the terminalId definitions from all connector’s breadboard layer line as the terminalIds are not in the svg. This doesn’t hurt anything, Fritzing ignores it but the parts check script complains and it isn’t correct.


Breadboard was mostly ok, it lacked a layerId (which breaks svg export in Fritzing), needed to be rescaled (as did all the svgs) . I increased the height of the encoder to match the real part (it was a couple of mm short in the original) and copied (probably poorly :slight_smile: ) the connector from the encoder datasheet to indicate that it is a shrouded connector. I reduced the pin size to make the individual pins stand out better. Removed unnecessary transforms (possible performance issue, transforms imply a matrix multiplication at every render.)


Again rescale the svg, change the units from px to in (px can cause scaling problems a Fritzing will guess at the original resolution 72dpi or 90dpi, I don’t think it knows about the current 96dpi), inches or mm isn’t subject to guessing. Made an alternate schematic with a standard box outline (alt schematic), but it isn’t much smaller than the one with the outline of the encoder and I think the outline of the encoder one is clearer and so should be the choice. Again removed unneeded transforms and unneeded parameters in the xml to reduce size / increase performance. The main user visible change here is adding terminalIds to the pins which corrects the “line terminates in the middle of the pin” problem you see in the original part. Without a terminalId Fritzing uses the center of the pin which looks ugly. I think the size of the original encoder is an example of the scale problem, as both sets of xml should be identical, but the possible part one is set to inches so scales correctly.

pcb, again rescaled and removed transforms. Fairly major changes here. In practice I don’t think it is likely the encoder will be mounted on the PCB. The connector (from the data sheet) doesn’t look like it would fit in a PCB, it is expecting an AMP connector and wires. Thus I replaced the connections with a 5 pin .1 header (and adjusted the hole size to 0.038 in, standard for .1 connectors). I also followed the original developer’s recommendation and removed the text in pcb view. The theory is that if the user wants the labels on silkscreen in pcb, they can add them via the text function in Fritzing, but if they are in the part, the user would have to make a new part to remove them. For reasons I don’t understand, the original part silkscreen renders very poorly in the gerbers (the xml looked pretty normal to me so I don’t know why exactly), I didn’t poke further because I wasn’t planning on using it on the final part. If you see something you don’t like or something I missed, please post here so I can correct it. The final objective is to get this series of parts added to the core parts distribution.


Now the router part

router.fzpz (5.1 KB)

router-orig.fzpz (6.2 KB)

Since this won’t fit on a pcb (it is entirely sockets) pcb view is suppressed. There is also an apparent Fritzing bug, in that the long url in this part causes the formatting of the description in Inspector to break.

breadboard view:

Breadboard is much the same as the original. Internally it was rescaled and unneeded xml and translates were removed. The user visible change is to move the connectors to align on a .1 in boundary and change the connectors to be smaller and at the edge of the connectors.

In schematic, same thing, rescaled removed unneeded translates, and xml add terminalIds to make the pins connect correctly. The major change is remove the replace the router outline with a more standard (and much smaller, which is why to do it!) box type schematic. In general the smaller the better in schematic to allow the most symbols on a single page.

On to the PCM part.

PCM-orig.fzpz (23.2 KB)

PCM.fzpz (25.0 KB)

As before the parts have different moduleIds and thus can be loaded together. One change (busing the CAN connectors) needs verification. I’m assuming that the CAN high connectors connect together as do the CAN low connectors, but I don’t have a module to verify that. If you click on one of the CAN pins (high or low) the other will also light up yellow to indicate they are internally connected together. If that isn’t correct, the bus needs to be deleted. As before I added a description of the device and the url to its web page to the fzp file and added descriptions to all the pins (so the description will come up if you hover over a pin). As with the router PCB view is supressed as being not useful. Breadboard is mostly the same, except I changed the connector pins to be smaller and invisible (they light up red if unconnected and green if connected). I can go back to the original if you prefer very nice job on breadboard by the way).

Schematic is a major change. This is what we were looking for in schematic:

The original IC one is functional but not very useful for figuring out the connections. As noted pcb has been supressed (the original IC footprint and the headers used for testing here show up, but the new part does not as PCB is suprressed.) On to the next part.

Now the PDP (Power Dirstribution Panel part. This one has substantial changes as the pin numbering in breadboard was an odd sequence and schematic was non existent (due to not enough connectors defined) and thus needs a good check. I don’t have a unit so am going by the documentation and the original part. Again PCB view is disabled as this isn’t useful on a PCB.

PDP-orig.fzpz (33.4 KB)

PDP.fzpz (44.9 KB)


The usual rescale and clean up xml, in addition this time a complete renumber of the pins starting with 0 at channel 0 - and proceeding in order around the perimeter. As well all the grounds are bused together (click on any ground and all the rest will light yellow) as do CAN high and CAN low. I copied the breadboard of one of the screw terminals to give a bit more life like representation of the power pins.


Created as the original doesn’t render as it is a 36 pin IC but there are 44 pins which is what causes the red square in schematic.


Now the roboRIO part. For this one I switched to a part that I made a couple of years ago that had the schematic already. The delay in posting this was caused by cleaning up a 2+ year old part (I knew a lot less about part making at that point) but it is now done and I have some improved tools for cleaning up parts because this was to complex to do manually in any reasonable amount of time.

roboRIO.fzpz (221.6 KB)



The power and grounds have been bused, one thing I’m not sure of is if the alternate connections on the MXP connector for SPI and I2C are shared with the associated pins on the dedicated SPI and I2C connectors. I have assumed not (the manual doesn’t say and I don’t have a unit to test). If they are common, then additional bus elements need to be added to indicate that.

Next the TalonSRX. This part needs a good review (preferably with the hardware at hand, because the documentation isn’t clear) as it is essentially a new part. The original part didn’t have the data port implemented, which is likely fatal, as that is where the encoder (one of the previous parts) connects. While reading the documentation to figure out the pin numbering on the data port I tried to swipe the image in the pdf for breadboard. It turns out that image is a bitmap and Inkscape (or me using Inkscape :slight_smile: ) had trouble converting it to vector. So I recreated it using lines, somewhat time consuming but successful I think. The CAN ports appear to be under the negative input wire but the documentation isn’t clear. So I moved them (on .1 boundaries) to beside the negative input terminal and assumed CAN 0 is closest to the negative wire (that needs to be moved if that isn’t the case!). The data port is shown with the dust cover removed so the connector is visible.

New part:

TalonSRX.fzpz (14.1 KB)

Original part:

TalonSRX-orig.fzpz (5.1 KB)



The connection in the middle of the pin is caused by no terminalIds in the svg.


On to the VRM module. This one has relatively few changes.

VRM-orig.fzpz (8.9 KB)

VRM.fzpz (9.8 KB)


most of the change here (other than rescaling and correcting colors and font sizes which are by and large invisible) is to reduce the size of the connectors to more closely match the size of the tabs on the real unit.


More changes here, as the original has only 16 pins against the 18 in breadboard and thus schematic was entirely broken (the red screen of too few connectors, or in this case the green screen with two connections to the center of the part).

as with most of these pcb is surpressed as not useful.


Now the final part, and a new (to me at least) Fritzing bug, the YumoE6B2 encoder.

YumoE6B2-orig.fzpz (5.0 KB)

YumoE6B2.fzpz (6.5 KB)


There are three parts here the previously posted (but now updated) AMT103 encoder and the YumoE6B2. The most user visible change in breadboard is changing the connection to a cable as in real life with the wires color coded according to the data sheet.


here we see the new Fritzing bug: The first encoder was originally enc1 (instead of the current cui-enc1) however with the YumoE6B2 also with label enc there were two enc1s which were different parts. We need to find out a way to detect a label is already in use and increment the count (even across different parts) to avoid confusion. Otherwise schematic is pretty identical, I added terminalIds to get the pin join proper and reduced the size of the encoder outline to save precious schematic space. Unlike most of these parts, both encoders have a pcb section as they connect via wires to (probably) .1 in headers on a board and are useful in places other than the First parts. Since it is unlikely the encoder would be mounted on a PCB, I removed the encoder outline from pcb silkscreen. As well the original part has a problem in pcb, where it is only one layer (I didn’t check to see why), it only appears and is routable on the bottom layer instead of both layers as in the new part.

This should be all the parts in the pull request, so once the author checks them to make sure I haven’t screwed anything up we should be able to submit them to core parts.