Good night Fritzing forums!
I have completely reworked an old but common sensor module for Arduino projects, the MPU6050 (GY-521 Breakout board) which is basically an accelerometer plus gyroscope for robotics and such stuff.
I made it since I wanted to improved an old fritzing version available here to be more appealing at breadboard and pcb design.
Made from scratch in like 4 hours 
InvenSense_MPU6050.fzpz (18.6 KB)
In the PCB view VCC doesnāt have a round connector on the square one.
In case @Old_Grey 's comment isnāt clear the parts check script has this to say (and is correct, there is no hole being generated for pin1 in the gerber as only the square is present, it needs a circular pad just like all the rest under the square to generate the hole):
Error 74: File
āsvg.pcb.MPU6050_GY521_782354e339f672575bb20992ece4ab1b_9_pcb.svg.bakā
At line 65
Connector connector0pin has no radius no hole will be generated
Peter
Thanks, I just came back to home and will fix this as soon as I can. Good catch 
Does the part checker fix problems, or just reports them?
Just reports them, its up to you to find and fix them (at least most of the time, for some things like reference file names it does correct things).
Peter
Mostly fine, a couple of nits: the holes are .040 rather than the standard .038 for a .1 header pin. Either should do (I think .040 may round up to .042 or thereabouts though but Iām not sure). You can fix that in Ink (assuming 10.4667 scale and 20 thou stroke width) by changing the hole diameter in the tool bar from .080in to .078in height and width. That will move the center of the circle (which you donāt want) so in xml editor note the new radius value (and make sure it is r not rx and ry which makes an ellipse) and undo your change so the pad goes back to the correct position. Now in xml editor change the radius to the value for a .038 hole you discovered above. Changing the radius (rather than the diameter) leaves the center x/y position intact and changes just the diameter of the circle so you donāt have to move the x/y coords of every pin. Repeat this for all 8 pins. The second nit is you have eliminated the square on pin1 in pcb. If you add a square with height/width the same as the circular pad on top of the pad and aligned to the x/y coords of the pad you have the square will come back as it is currently in breadboard (and I assume on the real board).
edit: a look at the pcb svg says Iām wrong (as is the original maker). The stroke width is set to 17 and needs to be reset to 20, the diameter is .074 (r 28.5) and a stroke-width 20 part needs a radius of 29 to make a correct .038 hole in the correct position.
Peter
In which view?
So I only have to change things at PCB? 
EDIT: InvenSense_MPU6050.fzpz (19.2 KB)
Okay it is done, I will stop making changes to this part xD
Also, here is a reworked version of ultrasonic sensor HC-SR04 that was made by Richard. I hope I renamed it like the current one so it gets overwritten when uploading to github.
HC-SR04 Ultrasonic Distance Sensor.fzpz (51.8 KB)
Unfortunately no to both. The part is still incorrect. From the gerber drill file obtained by exporting the pcb to gerber file->export->for production->extended gerber, in my case Untitled Sketch_drill.txt:
; NON-PLATED HOLES START AT T1
; THROUGH (PLATED) HOLES START AT T100
M48
INCH
T100C0.037000
T101C0.040000
%
T100
X014222Y008222
X014222Y010222
X014222Y007222
X014222Y011222
X014222Y012222
X014222Y009222
X014222Y013222
T101
X014222Y014222
T00
M30
we see a number of problems: the hole size is .037 (not .038) for 6 of the holes, one hole is .040 making pcb incorrect. Switching to svg.pcb.MPU6050_GY521_782354e339f672575bb20992ece4ab1b_9_pcb.svg (the pcb svg in your part) there are also a number of problems: The first group g58 has a translate. In pcb translates get tricky in that the values are supposed to be inherited but that doesnāt appear to always happen. The safe way is to eliminate all the translates in pcb. The next problem is that pads donāt have my corrected parameters (Iād guess because of the translates being used to change the coordinate space to approximate the correct values because they are almost right). I donāt see why one pad is .040 instead of 0.037, but my guess again will be translate somehow. As I said the r wants to be 29 not 28.5 and stroke-width wants to be 20 (with no translates) which should produce the correct size holes of 0.38. So in Inkscape xml editor I selected the top group (g58) and then hit shift-cntrl-g to ungroup until there were no groups left. The left me with pin0 with a stroke-width of 17.x and the rest at 20.x and the radiuses at 28.5. Using xml editor to change the radius to 29 and the stroke-width to 20 and then regrouping silkscreen (including the text) and copper1/copper0 should produce the correct pcb svg. The different stroke width on pin0 will be why the one pin was a different size (and indeed appears to be caused by the translates).
Iāll look this one over in a bit. Unfortunately like many things in Fritzing, replacing an existing part is complex (there are special undocumented anywhere I am aware of commands in the fzp file for doing this). What usually happens is that el-j (the parts maintainer) manually does this because he knows how and at least I donāt which is why there can be a delay in getting a part added and sometimes a part will be rejected as it canāt be converted
edit: Again a number of problems: Schematic and pcb arenāt scaled to 10ā¦41667, schematic pins arenāt aligned on .1 boundaries (they are a little high, possibly an artifact of the original not having height/width specifed in inches but rather px and being misscaled). Pcb doesnāt have an outline of the size of the complete board in silkscreen and the connector holes are 0.030in and should probably 0.038 for .1in header pins which is typically what these boards come with.
Peter
I donāt know how to read those gerber errors (since I havenāt generated any yet), but glad you wrote the correct fixes to that.
Looking at what you wrote, you mean the PCB view, right? So how to remove the transformation things like the translate at Inkscape?
I think the same thing can be achieved using the xml editor outside Inkscape using Notepadd++ or any code editor and just change the appropriate properties.
Forgot that one, once again, why it is neccesary? 
Was done on purpose since the original one was like that. It is because the sensor isnāt going to be placed on the PCB but the connectors since it is more like āplace-replaceā part. Following that principle, someone willing to use an ultrasonic sensor only has to worry about where are placed the pin header or holes in case of soldering.
EDIT: I have done the correction to the MPU6050 as you stated above and ran the gerber export option in order to check if there was an error. So far so good
InvenSense_MPU6050.fzpz (18.4 KB)
You could make a silk of the ultrasonic sensor from the top down, and that way when it is mounted vertically on a PCB you could see if it hits other vertical parts, ie ultrasonic sensors.
Yes pcb view (apologies, Iām so used to which is which I donāt even think about it). The way I remove the translates is usually manual ungrouping in Inkscape. Deepungroup (which ungroups recursively) does not remove the translates only shift-cntrl-g in Inkscape does as far as I know (and in some cases even that doesnāt remove them, notably polygons). If I canāt delete a translate any other way, I select the item and record its x/y height/width values from the top tool bar, then in xml editor I select the translate and blank out the translate value and set it. This remove the transform but also moves (and possibly rescales) the item so its coords in the tool bar are now incorrect. I then set the values that the translate originally had back in to the tool bar which usually will move and if necessary rescale the item without using a transform (as long as the item isnāt a member of a group, if it is in a group Inkscape will usually use a transform to change it). As noted this doesnāt work for polygons (but isnāt vital either, polygons with transforms are usually not a problem for Fritzing). Its a big pain in the ass, but the only way I know to get rid of the transforms if they are causing trouble. If someone knows of a better way I would love to hear it.
absolutely correct, for large numbers of changes that is what I do using regular expression replacement in the text editor. Any way that works and you are comfortable with is fine.
It isnāt necessary, the part will work fine (all other things being equal) with the current scale. It is suggested that this scale be used for parts in the part file format document because it makes 1px be 1thou in. If all the parts are scaled the same then the parameters in xml editor (in this case calculating the size of the drill holes) is easier because we know stroke-width should be 20 and hole size is pad diameter - (2 * stroke-width). While it is always possible to do the math above, it is much easier to be able to only change the radius to a new (probably known such as 29 for a 0.038 hole) value. You will find lots of parts that are not scaled properly but work fine. Iād like to see them all translated to the correct scaling for ease of modification (others may not agree).
By and large it looks fine, however I think one connector is slightly misaligned. From the gerber drill file:
INCH
T100C0.038000
%
T100
X019217Y014222
X020222Y014222
X018222Y014222
We see the first X coord of the holes X019217 is 5 thou (I think!) smaller than the others at X018222 and X020222 when they should all be the same. In practice it may not make any difference but I prefer precise (as you have probably discovered ). The why is more of a problem. With the tool bar set to inches all the pads look fine (and thus probably are fine). The problem looks to be connector1pin, its y coord in px is somewhat smaller than the rest which is what I expect is causing the change in the gerber. That would indicate it is likely round off error in Inkscape and can probably be ignored.
I tend to agree with Old_Grey on this one, but it is really the decision of the part maker, and your argument is likely correct, the real pcb is likely to connect via wires to the sensor (which is sometimes mounted on a servo and thus moves). That said the silkscreen doesnāt hurt anything and if someone does mount it on a board they will get some idea of what other parts the sensor may interfere withā¦ Your choice! You are learning well although as we said there is a lot to learn ā¦
Peter
Done I checked the part with Atom Editor so the .svgs files should look ābeautifulā since I used a beautifier plugin while working on them.
HC-SR04 Ultrasonic Distance Sensor.fzpz (51.2 KB)
Yeah, you were right, he was slighty missaligned so I had to manually set it to 147.637821 (was 146.262) like the others.
InvenSense_MPU6050.fzpz (18.4 KB)
Both parts now look fine. Congratulations! When I first exported the InvenSense part as gerbers I screwed up somehow and it didnāt render the top silkscreen. I didnāt see anything wrong in the svg to indicate why so I tried again and this time it rendered correctly (as the svg said it should) so I donāt know what I screwed up the first time, but all looks well. I assume the atom editor has a svg pretty print function. The parts checking script does the same thing, it will pretty print all the svgs on output (because lxml that does the parsing removes all input formatting).
Peter
That works well for me! Good on you for spending the time!
Helping folks make parts helps us all. We have a bunch of new parts from a variety of people as a result of it. A number of us are more than willing to help folks that want to make their own parts (and sometimes make parts for people that need one.)
Peter