By Jody Muelaner, Ph.D. CEng MIMechE

BriefBike is an e-bike designed to fold in a single, almost instant motion, just like an umbrella. This is a great case study in mechanism design due to the many constraints that must all be considered to ensure the bike performs correctly when being ridden and folded and when in its folded state. I’ve written before about how the constraint-based sketch tools in SolidWorks can be used to solve some relatively simple mechanism synthesis problems. In this article, I show how these techniques can be extended, using scripting and data filtering, to solve a highly complex mechanism design challenge.

BriefBike was designed to fold as quickly and easily as an umbrella, but the initial design was a bit too wide, and there were issues with the way the height of the seat was adjusted. This work optimized the mechanism to provide a more compact fold with enhanced riding geometry.

In a previous article, I introduced how geometric constraint-based sketching can synthesize mechanisms. This article takes the ideas further, providing a real-world example of optimizing a mechanism with many different constraints. Most notably, it shows that it becomes impossible to formulate a single sketch that can encompass all these constraints to directly solve for the optimum solution.

The method, therefore, only uses the geometric constraint sketch to solve the mechanism for a given parameter set. This can be repeated many times for different combinations of input parameters, recording output parameters for each configuration. All the results can then be listed in a spreadsheet, filtered to remove configurations that don’t meet essential criteria, and sorted to find the optimum design. Using a spreadsheet at this stage also allows metrics to be calculated to combine parameters, even potentially creating a single objective function that can be used to rank designs using a single metric.

Using macros to solve large numbers of configurations

In practice, updating parameters in the sketch and recording driven parameters in a spreadsheet becomes time consuming and error prone as soon as there are more than a few parameters to update. For example, with seven parameters (or factors) and just three parameter values (or factor levels), there are 2,187 configurations. Even if you could update the parameters in the sketch and record the values in Excel for one configuration in just one minute, it would still take a week of tedious work. Using Excel-driven configurations in SolidWorks may seem like the obvious solution, but in practice, this doesn’t work well for a very large number of configurations. The solution is the use the SolidWorks API to open the file, read in the parameter set, rebuild the model, and store the results. We created an application to do this, which uses three simple text files for inputs and outputs:

• Inputs.txt: This file is created by the user to define the problem to be solved. It has three lines:
  • The file name of the SolidWorks part to open and interact with
  • A comma-separated list of the driving parameters to be updated by the script
  • A comma-separated list of the driven parameters to be recorded by the script
• Parameters.txt: This file is also created by the user. Each line represents a different configuration as a comma-separated list of values, with each value corresponding to one of the driving parameters listed on the second line in inputs.txt.
• Outputs.txt: This file is created by the script. It has a similar structure to parameters.txt, with each line also representing a different configuration as a comma-separated list of values for each parameter. In this case, it is the driven parameters listed on the third line of inputs.txt that are listed.

The mechanism design process involves first defining the problem in SolidWorks, generating configurations in Power Query, solving all configurations using a SolidWorks API script (we’re using an in-house code DimWorker.exe), and then identifying the optimum solution by analyzing the results in Excel. Experimentation and iteration are likely to occur at multiple points within this process.

Understanding the constraints

A demonstrator had already been created, which proved the bike could be unfolded in less than half a second. However, it was still a bit too wide when folded, and optimizing the mechanism to further reduce the folded width without impacting the important ride characteristics was proving challenging. The large number of constraints that needed to be simultaneously satisfied meant that a direct solution to find the optimum mechanism was not possible. This method of using a script to generate multiple solutions was therefore created.

The key criteria for BriefBike can be summarized as follows:

• Folds and unfolds in a single effortless motion into a roller case format
  • Less than 500 mm wide, able to roll behind a person through doors and crowds, and fit second-stage luggage fold
  • Approximately 1,100 mm in height, providing correct grip height for rolling along
  • Less than 150 mm thick to conveniently store flat against a wall and be held tight against the body when in confined spaces
  • Transmission angles must be greater than 30° so the linkage does not bind
• Second stage fold that reduces the height to under 700 mm to be within the standard luggage size for trains internationally (700 x 500 x 300 mm)
• Stable two-wheeled trailing-link design when in roller case format, explained below
• Riding geometry must be comparable with a conventional bicycle. The most important parameters are the head angle, trail, wheelbase, position of the bottom bracket between the wheels, and effective stem length. These parameters are illustrated where the parametric sketches are defined later in this article.
• The frame must be structurally efficient. Dimensions measured on the sketch can be used as inputs to free body diagram calculations for truss joint forces at the Excel stage.
• Parts must not clash with each other during the folding process, and various clearance dimensions with the defining sketches reflect this requirement.

What I mean by a stable two-wheeled trailing-link roller case format can be easily understood by considering the two different types of roller cases commonly available. First, there is the four-wheeled variety that you push in front of you. The four wheels form a reasonably stable base and roll along fine on smooth surfaces. However, if the surface is rough or you want to break into a run, the small base and high center of gravity mean they tip over easily. And then there are the two-wheeled roller cases that drag behind you. In this case, the base forms a stable tripod between the wheels and your hand. Even if you suddenly accelerate or run the case straight into a curb, the wheels lift off the ground and land again in a stable position, and there is virtually no tendency to tip over. While many folding bikes include wheels that allow them to be moved like a four-wheeled case, BriefBike is designed to be pulled along like a two-wheeled case.

BriefBike was designed to have a wide two-wheeled base that can be easily dragged behind you. This is quite unlike current folding bikes, which are more like the much less stable four-wheeled roller cases. Even when they are pushed on two wheels, they perform in the same unstable way because they are narrow and pushed in front of you. Only a flat, wide wheelbase dragged behind you provides stability required to move at speed over rough surfaces when the propulsive force provided by your hand is applied at a height way above the wheels.

The driving parameters define the mechanism using two sketches. First, a sketch defines the ride geometry using ten parameters, including the wheelbase, trail, head angle, reach, and crank length. The head angle is driven by a linear dimension, as inputting angles using the API proved more difficult.

The RideGeom sketch defined the important parameters affecting the handling of the bike. This was then used as a reference for the LinkSynth sketch, which solves for the linkages that enable the bike to fold.

The second sketch is the one that actually solves the mechanism synthesis problem. It achieves this by drawing the mechanism in the folded and unfolded positions, defining certain key parameters but allowing the constraint-based solver to determine link lengths and joint positions to achieve the required motion. A great deal of trial-and-error experimentation was required to find a robust way of constraining this sketch with dimensions that allowed many different configurations to be tested without the sketch failing to solve.

The LinkSynth sketch is where all of the mechanism synthesis actually happens. The main folding mechanism is a four-bar linkage; the ground link is not shown. The three remaining links are shown in the riding position with a thick dotted line and in the folded position as a thick solid line. Other construction, steering, and envelope geometry are shown with a thin line. The wheels are only shown in the folded position, and the front and rear axles of the frame are mated to the RideGeom sketch, which is hidden in this view. The fixed ground link is represented by having the joints where the links connect to it coincidentally. The links are set to be of equal lengths in the two positions, and angles are also forced to be equal by triangulating and setting equal length constraints on the diagonals.

The large number of parameters in the model means that even when using automation, parameter levels must be selected sparingly. If the 16 driving parameters were each given five values, there would be 150 billion configurations. With each configuration taking about 0.1 seconds to rebuild and store the parameters, this would take 480 years!

In practice, with larger parameter sets, memory issues with storing all the outputs mean the time per configuration can increase dramatically. Even much smaller parameter sets can therefore become unfeasible. So, while an automated optimization allows far greater experimentation than you could hope to achieve manually, you still can’t just get the computer to try every possible configuration. Therefore, it’s a good idea to start by manually exploring the parameters to determine which are most sensitive and then use the optimization code to explore combinations of potentially interesting parameter values. This design was explored through six iterations of optimization, with between 1,000 and 40,000 configurations in each.

Setting up Excel to generate configurations and filter results

Once you have selected a set of parameters to explore, you must generate a table with all the combinations. This is known as a full factorial set in the design of experiments. The easiest way to do this in Excel is by using Power Query, another Microsoft tool bundled with Excel. The process involves connecting tables in an Excel workbook to queries in Power Query. This is a bit too involved to explain fully here, but it’s not difficult and is explained well in this YouTube video. Once Excel has generated the table of configurations, this can be copied and pasted into Parameters.txt.

The 18 output-driven parameters were copied into an Excel table with the 15 input-driving parameters. An additional 25 columns were added to calculate other quantities from the parameter values; these included clearances between components and forces calculated at joints. All configurations were then filtered to ensure sufficient clearances and identify the most desirable characteristics, such as longer wheelbase, steeper head angle, more direct transmission angles, lower joint forces, and a more compact folded package. These selection criteria were drawn from driving and driven parameters and values calculated in Excel.

Results

This mechanism optimization work resulted in a bike with a longer wheelbase, steeper head angle, and longer trail, all resulting in a more stable ride. At the same time, the frame is more structurally efficient, and it folds into a much more compact package. You can find out more about BriefBike at http://www.betterbicycles.org.