Version 2 creates higher quality output without ragged edges at higher speed. Like before, undercuts as needed for small tooth counts are correctly handled; clearance, backlash, and profile shift are fully supported.
As an extreme case the image on the left shows a 12 tooth gear meshing with a 5 tooth pinion (tool link). Notice the extent of the undercut. The image on the right (tool link) shows the same gears but this time with profile shift applied. The profile shift considerably strengthens the pinion gear teeth.
The key differences of v2 compared to v1 are:
Modern SVG output
Higher quality output (no ragged edges) without excessive segment counts. No more need to fiddle with quality parameters.
Significantly faster than v1 at any acceptable quality levels
Parameters are automatically injected in the URL; i.e., the URL fully specifies the output and can be shared with others.
Corrected internal gear generation (e.g., clearance is properly applied)
In case you are interested in how the gear shapes are created, the first post that introduced version 1 is a good start. Then this pdf document provides more detail about how v2 accomplishes the smooth curves that v1 struggled with. Internal gears are particularly challenging in this regard. Here is just a teaser:
I have been fascinated by clocks for a long time and finally took the time to build a wooden clock myself.
The clock is based on Brian Law’s plans for his clock 22. I chose it for its fascinating and novel gravity escapement that Brian Law designed (for more details see his blog post with precursor post).
The action of the escapement is best seen in the videos of the running clock.
The wood (cherry for the gears, hard maple for the lighter color parts) was cut on my CNC router. The need for accurate round parts was a great excuse to finally acquire a mini lathe and learn how to use it. The gears have been finished with multiple coats of thin CA glue with a final scuffing of the surface with 0000 steel wool for a semi gloss finish (see Chris Wrong’s article for a description of the process).
This open source Grasshopper Escapement Builder is based on the description published by Guy D. Aydlett: The Anatomy Of The Grasshopper (the pdf file has been shared by jrbeal on his clock forum). I am aware of shared spreadsheets that implement the equations but as far as I know this is the first online tool that generates Grasshopper escapement drawings.
Here are two sample outputs showing the exit pallet facing left (first drawing) and right (second drawing) based on different values for the pallet span N (5 and 9 for the left and right drawing, respectively).
I am very happy that Claire Huang allowed me to feature her 3d printed escapement which is based on my online escapement builder:
The gear meshing with the lantern gear is created by tracking how the lantern gear pins cut into the disk of the matching gear. As an example, the image on the right shows the path of one lantern pin moving clockwise into the 3 o’clock position. The same circles, pinned to the matching gear, create the shape of a half tooth as the matching gear turns counterclockwise at a speed defined by the gear ratio. (I use the same mechanism for the involute spur gear builder).
UPDATE: This post refers to an old version. For information about version 2 see this post.
Before you read on, please make sure that you have seen part 1 which introduces my Online Involute Spur Gear Builder. This second part addresses DXF export and compares the generated tooth profiles with the output from a commonly used OpenScad script.
Unfortunately there are many variants of the DXF format and not every tool is capable of importing the dxf output generated by the tool. Here are a few pointers:
Inkscape: Inkscape is a free, open source vector graphics tool that can import the generated dxf output without any issues. Inkscape’s native format is svg but it also supports many other output formats that are useful when dealing with other tools.
Illustrator and VectorWorks do not seem to recognize the generated output. Lael and Jeroen Donker reported workarounds (thank you, both!):
Lael: Just an update for anyone else trying to use illustrator or having issues importing into drawing programs. I downloaded Dassault draftsight, opened the dxf generated by this generator, then saved it as 2009, 2010 and 2013 dxf. 2009 and 2010 opened fine in illustrator.
Jeroen Donker: I found that the dxf output file can be opened in Inkscape (freeware on all platforms) and then saved in any vector format (I use eps) Opening the file in Adobe Illustrator is an easy next step.
Generated Output Comparison
It is interesting to compare the generated output with that of other tools. In particular this makes it quite easy to see when the undercuts become relevant. For the following I used Leemon Baird’s featured Public Domain Involute Parameterized Gears for OpenScad. Upfront I want to clearly state that this comparison by no means is intended to diminish Leemon Baird’s code. Like many other tools it simply does not cater for undercuts which in most real-world scenarios can be ignored. If undercuts are not an issue Leemon Baird’s tool is a perfect choice.
For the comparison I chose a pressure angle of 20°, 8 mm circular pitch, no clearance, and no backlash. For reference here is the scad file with the configuration for the 6 tooth gear and the resulting dxf file generated by Leemon Baird’s script.
The images below (excerpts from the svg file InvoluteGearComparison.svg) show the tooth profiles for tooth count 40, 20, 10, and 6. The thicker black background lines represent the output generated by Leemon Baird’s code. The thinner red lines in the foreground are the tooth profiles generated by my online generator:
As expected the two profiles match almost exactly for large tooth counts. It is interesting to see that even for a tooth count of 20 there is a slight undercut visible. I expect in real live this would not matter since it is compensated for by a non-zero backlash.
In order to have some ‘meaningful’ values to show on the LCD display the setup includes a potentiometer (any value between 5k and 50k should work) to create analog input values:
For details about the LCD display with I2C support see
The reviewer comments by docpayce and particularly JackWP associated with the two product pages above have been very useful.
Connect the LCD: VCC -> 5V, GND -> GND, SDA -> A4 (PortC4, ADC4), SCL -> A5 (PortC5, SDA)
The LiquidCrystal_I2C library needs to be downloaded and installed from here: https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
#define I2C_ADDR 0x27
#define BACKLIGHT_PIN 3
#define En_pin 2
#define Rw_pin 1
#define Rs_pin 0
#define D4_pin 4
#define D5_pin 5
#define D6_pin 6
#define D7_pin 7
LCD *myLCD = &lcd;
int SENSOR_PIN = 0; // center pin of the potentiometer
lcd.begin(16,2); // initialize the lcd
lcd.home (); // go home
lcd.print("Hello, ARDUINO ");
int sensorValue = analogRead(SENSOR_PIN);
// set cursor to second row, first column
Kudos to docpayce and particularly JackWP for pointing to, and figuring out the constructor parameters (see URL references at the top of the Arduino sketch).
The code behind the online involute spur gear builder determines the tooth profile by simulating how a gear with infinite radius (aka rack) would cut into a smaller gear as discussed by Michal Zalewki. The advantage of the infinite gear is that it has a very simple trapezoidal tooth form solely defined by the addendum height and the pressure angle. In the figure below the rack is shown at the top. When the rack is moved to the right the gear needs to rotate clockwise so that a point on the pitch circle of the gear moves with the same speed as the rack. The code simulates this movement in steps and then for each step subtracts the shape of the rack from the gear.
For illustration purposes the figure below has been calculated based on very coarse steps and only shows two teeth of the rack.
In reality the code simulates only one rack tooth and calculates the tooth profile of half a tooth of the matching gear. The complete gear is then assembled by mirroring and rotating the half tooth. All of this is accomplished by leveraging the ‘Constructive Area Construction’ capabilities of the csg.js library which is part of OpenJsCad. Each rack tooth location is calculated and created as a polygon. These polygons are joined together with the union operator to form one complex 2d shape that is then subtracted from a slice of the outer circle of the target gear to form half a tooth. Finally, the complete gear is assembled from rotated and mirrored half teeth:
The graphic above shows rough steps in the final output. This can be somewhat alleviated by using finer steps in the simulation but to really get rid of the steps additional smoothing is required. The step profile occurs in the undercut regions where the backside of the rotated rack tooth profile sticks out as a corner. The smoothing logic is explained in this diagram:
The final result has smooth tooth profiles. As an example below is an image of a calculated gear set (pressure angle 14.5°) consisting of a 30 tooth gear meshing with an 8 tooth gear. Small values for clearance and backlash were used. Head over to the involute spur gear builder page to try it out yourself.
Please see part two for more information about dxf output and how the output compares with that from other tools.
Split the Quality parameter into two parts to provide better control over the desired quality of the generated output:
Almost exactly a year ago I published a blog post introducing an open source application for calculating cycloidal gears. The response was very positive but the fact that the tool depends on a specific version of .Net makes access a bit cumbersome. Also the tool does not immediately show the resulting gears. Instead the user has to save the output as an SVG file and then display it either in a browser or an SVG editor like Inkscape. No instant gratification there.
The IBT-2 H-bridge module from wingxin is an inexpensive, high power motor driver based on two BTS7960 chips and is readily available from various ebay vendors; see e.g. here.
The link provides more details but here are a few key parameters.
Input voltage : 6V-27V
Maximum Current : 43A
Input level : 3.3V-5V
I am not sure whether the heat sink is sufficient for handling 43A but even if one does not drive the unit to its limits the specifications are still impressive given the typical price point of this module (currently between $13 and $17 including free shipping from China). There is relatively little information available about how to hook up the module with an Arduino controller. This thread on the Arduino forum was useful but the solution wastes a few pins and does not demonstrate bidirectional motor control. In this post I describe a slightly more complete solution that uses an Arduino controller with connected potentiometer to drive a motor via the IBT-2 module from full reverse speed to full forward speed.
For reference here is the description of the input ports and the two supported usage modes (image taken from one of the ebay postings). In this post I leverage usage mode one.
Here is the associated Arduino sketch:
IBT-2 Motor Control Board driven by Arduino.
Speed and direction controlled by a potentiometer attached to analog input 0.
One side pin of the potentiometer (either one) to ground; the other side pin to +5V
Connection to the IBT-2 board:
IBT-2 pin 1 (RPWM) to Arduino pin 5(PWM)
IBT-2 pin 2 (LPWM) to Arduino pin 6(PWM)
IBT-2 pins 3 (R_EN), 4 (L_EN), 7 (VCC) to Arduino 5V pin
IBT-2 pin 8 (GND) to Arduino GND
IBT-2 pins 5 (R_IS) and 6 (L_IS) not connected
int SENSOR_PIN = 0; // center pin of the potentiometer
int RPWM_Output = 5; // Arduino PWM output pin 5; connect to IBT-2 pin 1 (RPWM)
int LPWM_Output = 6; // Arduino PWM output pin 6; connect to IBT-2 pin 2 (LPWM)
int sensorValue = analogRead(SENSOR_PIN);
// sensor value is in the range 0 to 1023
// the lower half of it we use for reverse rotation; the upper half for forward rotation
if (sensorValue < 512)
// reverse rotation
int reversePWM = -(sensorValue - 511) / 2;
// forward rotation
int forwardPWM = (sensorValue - 512) / 2;
The following Fritzing diagram illustrates the wiring. B+ and B- at the top of the diagram represent the power supply for the motor. A 5k or 10k potentiometer is used to control the speed.
For SLAM and navigation to work correctly on a ROS based robot it is necessary to accurately specify the transformation between the coordinate system (frame) of the steering center of the robot (the frame is typically called base_link) and the coordinate system of the laser scans. In the case of Kinect based robots the laser scan measurements are derived from the 3d point cloud that is provided by the openni_camera package and is based on the frame /openni_depth_frame.
This transformation hooks together the base_link frame with the frames that are associated with the Kinect sensor. How the various frames are connected can be seen by running the following commands as described in this tutorial:
rosrun tf view_frames
Here is the result of running these commands while running the navigation stack on Ardros (click on the image for a larger view).
I marked the frame for the laser scan data in red. As can be seen this frame is now connected with base_link.
Now the question is, how can we determine the parameters shown in the transformation above. I found it easiest to ‘park’ the robot in front of a wall pushing against a rectangular piece of card board or foam board to guarantee that the front of the robot is oriented parallel to the wall at a fixed distance:
I use a book to create a step change in the laser scan right in the center of the front of the robot. Next I run the navigation stack and bring up rviz with a configuration file that shows the laser scan plus two axes displays for the frames /base_link and /openni_camera.
By setting the length of the base_link frame axes to the distance from the origin of the base_link frame to the wall I can readily see whether the laser scan line intersects with the end of the x axis (red). If it doesn’t then the x offset as specified in the static transformation broadcaster base_to_kinect_broadcaster (see the line from the launch file above) needs to be adjusted. Furthermore the step change in the distance needs to align with the x axis. Any mismatch needs to be adjusted by modifying the y offset in the transform base_to_kinect_broadcaster.
Once this is done the frames are correctly aligned and the navigation stack can accurately correlate the laser scan with the odometry information.