Monthly Archives: March 2018

To a man with a hammer, …

Posted 17 March 2018,

To paraphrase the saying, “to a man with a hammer, every problem looks like a nail”, “to a man with a 3D printer, every problem looks like a 3D printing opportunity”.  And that’s pretty much what happened when I ran across the problem of adapting some 80mm wheels to my Wall E-2 robot, which came originally with 65mm versions.  The extra 15mm diameter/7.5mm radius doesn’t sound like much, but it makes a huge difference when navigating over carpet or other small obstacles (like my wife’s slippers).

After a lot of work, I finally was able to print four reasonable quality adaptors, and thought I was home free.  Unfortunately, I soon learned that despite my best efforts, the printed adaptors were no match for physics; the wheel eventually worked its way off the motor shaft, just as before – it just took a little longer ;-).

After the usual number of curses, imprecations, and woe-is-me’s, I finally decided to use whatever was left of my engineering brain to actually look at the physics of the situation.  When I did so, I realized that my adaptor idea was never going to work.  While the adaptor did indeed (after the aforementioned ‘lot of work’) provide for a better fit between the 80mm wheel receptacle and the motor shaft, it also moved the wheel another 9mm or so away from the robot chassis, which put the wheel center of pressure (CP) well outside the adaptor-to-motor shaft parting plane.  This meant that the wheel would always be trying to pry the the adaptor off the shaft, and it didn’t take all that long for it to succeed :-(.  The following photo illustrates the problem

80mm wheel with 3D-printed adaptor on the left, same wheel directly attached to motor shaft on the right

So, contemplating this problem while drifting off to sleep I was struck by a solution; I could use a small roll pin inserted through the wheel and motor shafts to literally pin them together.  The geometrical physics would still cause the wheel to flex the shaft, but the forces wouldn’t be able to overcome the strength of the metal roll pin.  Because I knew I would forget this insight if I left it until morning, I staggered out of bed and jumped onto the McMaster-Carr site (they have everything!) to look for an appropriately sized roll pin.  I found a 1 x 6mm roll pin that would be perfect for the job, and if I ordered them now they would probably already be on my doorstep when I woke up in the morning.

McMaster-Carr metric roll pins

However, while I was doing the necessary measurements on the motor shaft, I noticed the motor shaft had a axial hole in it, and so did the wheel; hmm, maybe I could simply run the roll pin through the axial hole, instead of cross-wise?  Then I thought – wait that hole looks to be slightly smaller than 3mm – maybe I could simply drill/tap it for 3mm and use a 3mm screw (of which I had plenty in different lengths) instead of a roll pin?

So, in just a few minutes I had drilled & tapped the axial hole in the motor shaft of one of my spare motors, drilled out the wheel hole for 3mm clearance, and firmly screwed the wheel to the shaft (the right-hand wheel in the first photo above) – cool!

Now all I have to do is modify all four wheel shafts for 3mm clearance, and all four motor shafts to accept a 3mm screw – piece of cake!

As can be seen in the above photos, the 80mm wheels are now much closer to the chassis.  The wheel guards are now much too wide, but I may keep them that way for the moment, as I have already adjusted the charging station lead-in rails to accommodate the (now unnecessary) greater wheelbase – oh well 😉

So, the moral of this little story is:  Just because you have a 3-D printer doesn’t mean the solution to every problem is a new 3-D printed piece; and maybe to keep one’s eyes/brain open for even better solutions as they might come along when least expected!

Stay tuned,









New TP5100-based Battery Pack for Wall-E2

Posted 13 March 2018

In a recent post, I described my study of the widely available and dirt-cheap TP5100 1/2-cell LiPo battery charger as a possible replacement for my current Adafruit PB1000C-based battery charger.  Based on the results of this study, it was clear the TP5100-based system was superior in all respects to my home-brew system:

  • Twice the charge current (2A vs 1A) means significantly shortened charge times
  • Much smaller and simpler
  • Charger current path independent of load path – much lower IR drop
  • Battery always connected to the system, so no requirement for ultra-low-drop MOSFET diode
  • Much simpler software – no requirement to monitor status of two separate chargers
  • No electromechanical relay to screw up.

I constructed a small charger module using some perfboard and a couple of 2-place screw terminals, as shown below (with the previous module shown for size comparison).

New TP5100-based charger module, with previous Adafruit PB1000C-based module below for size comparison. The orange box contains 4 Panasonic 18650 cells.  Note the separate charge & load circuits

The following figures show the old and new schematics:

Old battery pack schematic

New battery pack schematic

Now that the load current doesn’t have to go through the charging module, I was able to replace all main battery wiring with #20 wire for lower IR drops, as shown below

Power wiring replaced with #20 wiring, and 2-pin Deans connectors

#20 wiring to main battery buss. Note in-line safety disconnect


The change to the new battery pack also considerably simplified the system hardware and software.  The changes to the system schematic are shown below:

Old system schematic. Note the ultra-low-drop MOSFET diode required to keep Arduino Mega alive during charge. and the number of pins required for charge monitoring.

New system schematic. No requirement for diode, as full battery voltage is available at all times. Also, only two pins are required for charge monitoring

The operating system software has also been simplified.  Now, instead of monitoring both cell voltages and four different status lines, only two lines have to be monitored.  Also, there is now no requirement to correctly sequence the ‘Charger Connect’ and ‘Coil Enable signals in order to accomplish correct charging station connect-disconnect behavior.  Now the system simply shuts off the motors when the robot connects to the station, and turns them back on again to disconnect.  As an added benefit, the six charge status LEDs have been repurposed to show a crude approximation (based on battery voltage only for the moment) of charge status.

All these changes have caused one minor hiccup in the implementation of the charging station; the new charging voltage is +12V vs +5V as before.  As you may recall, the charging station implements a square-wave modulated IR signal, and this signal is produced by a Teensy 3.2 and some associated circuitry, all of which expect +5V.  This will require either a dual-output supply, or the addition of an on-board 12-to-5V regulator. This is still up in the air, but I suspect it will land on a simple 3-pin regulator.

So far, all the hardware changes (except for the charging station changes) have been accomplished, but the software changes have yet to be implemented and tested. Stay tuned!



Bridge Game Reporter for Duplicate Bridge

Posted 10 March 2018


Some time ago I created Bridge Game Reporter (BGR), a wrapper for Ray Spalding’s wonderful Bridge Composer (BC) program, for the Columbus Bridge Center, our local bridge club.  Bridge Composer produces really nifty HTML and PDF reports of duplicate bridge games, but using it can become tedious, and non-technically-oriented bridge directors are prone to making mistakes when FTP’ing result files to a website.  So, my BGR program automates all that stuff and makes calls into the BC API to make the magic happen.  After the inevitable problems and issues, it seemed to be working fine at the CBC, and then Siraj Haji, owner/operator of the Aloha Bridge Club asked me if I would mind sharing the program with him.  Siraj had a slightly different setup, and rather than FTP’ing result files to a website, he wanted to email them to just those players who actually played in a particular game, so he and I worked out the strategy for using ACBL player numbers from session reports as a search key into a CSV-formatted email list.  After the usual number of mistakes, we got it working.  A few days later Siraj mentioned that he also uses Bridge Composer to generate game files for upcoming games, but it was somewhat tedious – could I maybe use my new-found BC superpowers to do something about that?  Well, it turns out that the BC guy (Ray Spalding) created a pretty nice API to BC, and provided a WScript/JScript example that did most of what we wanted.  After a few days of fumbling around, I figured out most of what was going on behind the curtains, and realized that I could fairly easily add a ‘game generation tool’ to my BGR app to add bulk game generation capabilities.  Again after the normal number of mistakes, Siraj reported that this feature seemed to be working – yay!

At some point in this process, after the email feature was added and before the bulk game generation feature, I got another request for the program from another club in the area, so I realized I was going to have to provide an actual installation program and some user documentation.  Since I already had this blog site, I decided to use it as the documentation vehicle.


Bridge Game Reporter Features:

  • Uses Ray Spalding’s Bridge Composer program, which must be installed and active for the magic to work.
  • Automates the process of calling Bridge Composer with the correct set of files for a particular game.
  • Optionally automates the process of FTPing Bridge Composer game summary and hand records to a selected website
  • Optionally automates the process of emailing results to a user-supplied list of email recipients
  • Automates the process of generating multiple games over a range of dates/times using the ‘Game Generation’ tool.

Main Page:

The main page of the Bridge Game Reporter program is shown below, along with a description of each control area.

Bridge Game Reporter main page

Game Date: The user selects the desired game date from a drop-down calendar display.  This date is used to construct the filename to be searched for. The file name format is in the form [yymmdd][session time].ext, where yy = year, mm = month, dd = day, session time = ‘M’ (Morning), ‘A’ (Afternoon), ‘E’ (Evening), or ‘L’ (Late).  All input files associated with a particular game will have this format.  For instance, for an afternoon game on March 6, 2018, the filename will be 180306A.ext, where ‘ext’ = BRI (or DUP or PBN) for the deal file, BWS for the Bridgemate results file, TXT for the text summary file, HTML for the report output from Bridge Composer, and LOG for the log file optionally created by BGR.

Game Time: The user selects one of ‘Morning’, ‘Afternoon’, ‘Evening’, or ‘Late’.  This selection is used to form the ‘MAEL’ suffix to the filename.

Lock Entry Fields: For a particular club setup, most of the fields dealing with file locations can be set once and then never changed again.  To prevent inadvertent changes to these fields, this option, when checked, will make them all read-only.

Game Input Folders: The location for the .BRI, .DUP, or .PBN game files, the .TXT summary file, and the .BWS Bridgemate score files.  The .BWS file can be skipped, if necessary.

Game Report Folders: The location for the .HTML and the optional .LOG files.  This section also contains the ‘FTP to Website’ checkbox and the the URL for the destination website, if this feature is enabled, and the ‘Email to List’ checkbox and corresponding location for the email list document.

Start, Close buttons and logging area: The ‘Start’ button will remain grayed-out until all required input conditions are met, at which time it will become click-able.  Clicking ‘Start’ will cause the program to assemble all the required information and send it to Bridge Composer for processing; then it will optionally transmit the results to either a selected website or to addresses on an email list.  The ‘Close’ button will close the program.  The logging area displays progress and/or error information. If the ‘Save log to folder’ option is checked, then the log file will be saved to [yymmdd][session].LOG in the selected folder.

Set FTP/Email Creds: FTP and/or email server login information (username & password) is saved in the ‘BGR.TXT’ file, which must be in the C:\BGR\ folder (this folder and a default file are automatically created at installation).  The format of the BGR.TXT file is


Clicking the Set FTP/Email Creds button will bring up the following dialog box for editing the contents of BGR.TXT.  This dialog is password protected, more to prevent inadvertent changes by untrained personnel than for any serious security.

Reset Folders to Defaults: Clicking this button will overwrite the current folder settings with the last-saved set of default settings.  This button (and the corresponding ‘Save Current Settings as Defaults’) are almost never used, as the program automatically saves the last set of user settings whenever the program is closed, and automatically restores them the next time the program is launched.


Emailing Results:

The email feature requires four components:

  • The session summary ([date][session].TXT) file produced by ACBLSCOR containing player names and ACBL player numbers
  • A user-provided file containing email addresses in CSV format (an example is provided)
  • A user-customized ‘EmailTemplate.txt’ email template file  (an example is provided) containing the body of the email to be sent
  • Any HTML/PDF attachments to be sent.  All desired attachments must have the same filename as all the game files for the particular session, with a .HTML or .PDF extension, and must be in the same folder.

The email list must be in CSV format, and must be formatted as follows:

Name,ACBL #,Email Address,Opt out
Jody Lastname,R892974,,
Daniel Lastname,N184169,,yes

A ‘yes’ (case-insensitive) in the ‘Opt out’ field will cause that address to be skipped.

The ‘EmailTemplate.TXT’ file format is:

Aloha Bridge Club results for [GAMEDATE] – [SESSION]

Thank you for playing. This automated email is intended solely for players in this specific session. Thank you for your support and cooperation.

In the above example, the FROM:, SUBJECT:, and BODY: sections are required fields, and must be placed as shown.  [GAMEDATE] and [SESSION] are optional fields that will be replaced by the actual game date and the actual session time (‘Morning’, ‘Afternoon’, etc).  The resulting email using the above template looks like the following, where ‘[GAMEDATE] – [SESSION]’ was replaced by ‘February 26, 2018 – Evening’

Game Generation Tool:

The game generation tool is intended to automate the process of batch-producing dealer (.PBN or .BRI) files for games over a range of dates and session times. if, for instance, you wished to produce the deal files for all Monday, Wednesday, and Friday afternoon and evening games for the entire month of April you could simply set up the dates and times, and press one button to generate all the game files.

The game generator tool is accessed from the main Bridge Game Reporter page by selecting the ‘Game Generator’ item under the ‘Tools’ menu.  The tool dialog is shown below, along with an explanation of each control section.


Start/End Date: The starting and ending dates for game generation (inclusive)

Game Times: Select one or more game time checkboxes to have that session time’s game generated for every applicable date.  Checking ‘All’ will enable all times, and unchecking ‘All’ will disable all times.

Game Days: Select one or more game day checkboxes to have games generated for all enabled session times for all those days of the week within the selected date range, inclusive.  Checking ‘All’ will enable all days, and unchecking ‘All’ will disable all days.

Selection Summary: This is a read-only running summary of the number of days, times, and total games to be generated.  It’s  a good idea to check that the ‘Tot Games’ number is what you expect, before starting the generation run.

Destination Folder: The folder to be used as the destination for generated game files.  This folder must exist, and must contain the template file ‘handrecord.pbn’ (see below)

Output Format: Bridge Composer can create game files in either .PBN or .BRI format – simply select which one is desired.

Number of boards to generate: Type in the desired number of boards to generate per game.  This will typically be 24, 27, or 36, but can be anything.   I suggest setting this to 2 or 3 when first getting used to the program.

Generate Games: Starts the generation process.  Note that this button won’t be enabled (click-able) until all the prerequisites are met (start/end date, days of week, session times, destination folder, etc).  If the button won’t enable, check the log for helpful messages.

handrecord.pbn template file: This is a required file, and it must be present in the folder selected in the ‘Destination Folder’ entry field.  This template file is used by Bridge Composer to customize hand record output for your club or organization, as shown below:

2-board game generated using the default ‘handrecord.pbn’ file

The above figure shows a 2-board game generated by Bridge Composer using the default ‘handrecord.pbn’ file.  The text in the title area above can be customized for your own club using Bridge Composer’s ‘Format Title Area’ menu as shown below

Once the required customizations have been accomplished, simply save the result back to ‘handrecord.pbn’, and they will show up the next time a game is generated.  Note that Bridge Composer supports many other customizations to the ‘handrecord.pbn’ template, but that’s an exercise that is left up to the user ;-).


Download and launch BridgeGameReporter.msi to install Bridge Game Reporter on your (Windows only – not MAC) PC.  The installation program will do the following:

  • Install the BGR application in C:\ProgramFiles(x86)\Bridge Game Reporter
  • Create the folder C:\BGR\ and place a default BGR.TXT file there for ftp/email credentials
  • Create another BridgeGameReporter folder in your ‘My Documents’ folder to hold the ‘handrecord.pbn’ file required for game generation, and the ‘EmailAddressList_Sample.csv’ and ‘EmailTemplate_Sample.txt’ sample files.
  • Place a red heart-shaped ‘BGR’ icon on your desktop

Once the installation completes, launch the program using the desktop icon, and fill in fields as required/desired.  Note that if you want to use the game generation tool, you should set the Destination Folder field to the ‘BridgeGameReporter’ folder in your ‘My Documents’ folder.