Jul 272019
 

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).

Here a few snapshots covering the build.

Mar 042017
 

For the impatient: Just head over to the Online Grasshop Escapement Builder page.

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).

Feb 192017
 

I implemented an online lantern gear builder to complement my other online gear generators.

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).

The complete list of gear builders is:

Jul 132015
 

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.

DXF Export

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:

ToothCount40ToothCount20ToothCount10ToothCount6

 

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.

 

 

Jan 112014
 

This is a quick description of how to hook up the LCD module to an Arduino. FastTech currently offers the unit for $5.83 (free shipping).

LCD1602Display_I2C-Front LCD1602Display_I2C-Back

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:

LCD-Display-with-Potentiometer_bb

#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>
/*
For details about the LCD display with I2C support see
http://www.fasttech.com/reviews/1380909/22072
and
http://dx.com/p/funduino-iic-i2c-1602-lcd-adapter-board-w-2-5-lcd-screen-black-green-red-173588
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

LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin,BACKLIGHT_PIN,POSITIVE);
LCD *myLCD = &lcd;

int SENSOR_PIN = 0; // center pin of the potentiometer

void setup()
{
  lcd.begin(16,2);               // initialize the lcd
  lcd.home ();                   // go home
  lcd.print("Hello, ARDUINO ");
  delay(1000);
}

void loop()
{
  int sensorValue = analogRead(SENSOR_PIN);
  // set cursor to second row, first column
  lcd.setCursor(0, 1);
  lcd.print(sensorValue);
  lcd.print("      ");
  delay (100);
}

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).

Jan 012014
 

For the impatient: Just head over to the Online Involute Spur Gear Builder page.

Still here and interested in some background? Perfect! Involute gears are by far the most commonly used gears today. An involute curve is fairly easy to calculate and quite a number of freely available tools and scripts exist that use this fact to create involute gear profiles (see e.g., Gear template generator, Parametric Involute Bevel and Spur Gears, OpenJsCad’s gear demo, and many more). However, I have not found a freely available tool that correctly caters for undercuts that occur for smaller tooth counts (around 10 or less):

UnderCutExample

If the undercuts are ignored the resulting gears will jam if machined and assembled precisely. For an elegant description of the issue including a recipe for how to graphically create correct spur gears see Michal Zalewski’s corresponding section in part six of his excellent Guerrilla guide to CNC machining, mold making, and resin casting series.

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.

InfiniteGearCutter

For illustration purposes the figure below has been calculated based on very coarse steps and only shows two teeth of the rack.

AnnotatedCutoutSteps

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:

CAG_AssemblySteps

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:

CutoutSmooting

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.

SpurGearExample

 

UPDATES:

Dec 292013
 

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.

All these issues are addressed in my new Online Cycloidal Gear Builder. Check it out!

2013-12-29-13_23_35-Cycloidal-Gear-Builder

Dec 282013
 

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.

IBT-2Module

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.

IBT-2-Input-Ports

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)

void setup()
{
  pinMode(RPWM_Output, OUTPUT);
  pinMode(LPWM_Output, OUTPUT);
}

void loop()
{
  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;
    analogWrite(LPWM_Output, 0);
    analogWrite(RPWM_Output, reversePWM);
  }
  else
  {
    // forward rotation
    int forwardPWM = (sensorValue - 512) / 2;
    analogWrite(LPWM_Output, forwardPWM);
    analogWrite(RPWM_Output, 0);
  }
}

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.

IBT-2-with-Arduino_bb

 

Feb 112012
 

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.

As described in my earlier post 2d SLAM with ROS and Kinect I specify the transformation between the base_link and the Kinect sensor (specifically the frame openni_camera) in the launch file ardros_configuration.launch. The relevant line is:

<node pkg="tf" type="static_transform_publisher"  name="base_to_kinect_broadcaster" args="-0.115 0 0.226 0 0 0 base_link  openni_camera 100" />

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
evince frames.pdf

Here is the result of running these commands while running the navigation stack on Ardros (click on the image for a larger view).

tf_frames

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:

CalibratingKinectLocation

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.

KinectLocationCalibration

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.

Feb 052012
 

As described in previous posts until now I used an Arduino Mega controller for my Ardros robot. In most cases this controller provides more than enough power. Mainly out of curiosity but also in order to overcome problems with encoder ticks counting when my motors run at full speed I decided to give the Leaf Lab‘s Maple controller a try.

The Maple is based on the 32-bit STM32F103RB ARM Cortex M3 microcontoller running at 72 MHz. Apart from the drastic speed improvements, what makes the Maple so attractive is that it uses the same pin layout as the Arduino and comes with the same IDE and hardware abstraction.

MapleIde

As a result the transition from Arduino is fairly easy. Naturally there are differences, though. They are summarized here.

The port of the complete Arduino program including the libraries that make up the Ardros – Controller and Drive System was rather painless and is now running on my robot. The source code is available on my Google code site drh-robotics-ros. This post is based on revision 104 of the code. The relevant subdirectories are Robot and libraries.