# Motorcycle Front End Geometry Explorer (webform / app)

Discussion in 'Some Assembly Required' started by sebwiers, Mar 5, 2018.

1. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
I'm working on some (free) software to calculate the changes to various dimensions (rake, trail, wheelbase, neck height, axle-crown length) that would result from fork length change, tree rake, neck chop / up / out, and wheel size changes. The software would then diagram either or both setups (overlayed) so you can get an vague idea of stance, etc. Its mostly aimed at chopper type mods (uses terms that make sense in that context) but would work fine for anybody doing custom trees, wheel swaps, fork swaps, etc. Math is the same in both cases.

https://sebwiers.github.io/motorcycle-front-end/

I have a few questions about what people might want from such a package.

First, are the changes it calculates useful? In theory I think those are enough that you can set up a build jig, but I'm not sure just what values a jig uses. I'm also assuming that when people talk about a change to neck angle (such as +3 degrees) this is a chage to the frame itself, basically cutting the frame and inserting 3 degree wedge (which would also result in some small amount of up / out) and does not necessarily mean that the final stance has 3 degrees more rake. Is this a common understanding & use of the term?

Obviously I still have some work - it draws the bikes correctly, but they are figured out such that both effectively are treated as being in a stand with the rear axle locked in place (or equivalently, held by the engine / trans mount). This doesn't really show stance change and potentially makes calculating trail difficult, but made some of the math (much) easier and is, I assume, how modifications like up / out / neck angle change are described / measured, hence my questions above.
mousitsas, Oyabun, DRjoe and 2 others like this.
2. ### SalsaBeen here awhile

Joined:
Dec 12, 2006
Oddometer:
980
Location:
Arizona, Alaska, Kalifornia
First, I would add dimensions so that the user knows what he is doing ( then the name is not as important in what it means). Showing the top and bottom of the head crown would help in the fork dimensions.

A future improvement could be a swing arm showing the limits of travel would be useful.

Farther out in the future, handlebars, a seat and footpegs could be useful.

Don
3. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
By dimensions, do you mean inch vs cm vs mm? It really doesn't matter what units you use (though they obviously all need to be the same).

I see your point re the measurement descriptions being confusing, though there should be some clarifications visible when you hover on the form. The top of the head crown is really not relevant to my math, and dealing with lines that have more points than just the endpoints defined is a HUGE pain in the ass for such a (supposedly simple) project. As would all those other image items like ergonomics. But I'll see if there's a way to do it... I could maybe draw it as an extension of the rake line that has a length equal to head tube length, and is drawn fat enough to look like a head tube. That way its still just a line with two endpoints and an angle I already know. Hmm...

What I plan to do to make things easier / more useful is allow the user to load / scale / move a background image. The idea would be that you take a picture of your bike (or whatever bike you are entering dims for) and put it in the background at a scale / position where the tires etc match up. That would show you both which dims related to what, and where the handlebar / seat / footpegs were. By having a default image (matching the default dimensions), the use of this (and meaning of measurements) would be made fairly obvious. And you'd be able to switch images between a stock / custom image. I'll be using my own bike as the default, unless I find a better example, but I'd like to also have a drop down selector that offers multiple options for pre-populated numbers / images. There would also be a "measuring tool" so you can get the (approximate, given the accuracy of mouse use) distance between any two image points.
So yeah... lot of work still to do!

The swing arm / travel limits would really be kinematics work. I plan to eventually do basic kinematics, at least for the front end. But I see your point that even in a static geometry program, it might be nice to see the travel limits... especially if there's a background image, so you can check if (for example) your planned fork changes would result in the front wheel hitting the engine. Definately something I will keep in mind for the long run!

Thanks for the feedback!
4. ### boatpullerLong timer

Joined:
Jan 4, 2012
Oddometer:
1,385
Location:
Central fly-over land.
I like your idea, a lot. This could be helpful to folks in this forum considering a dirt bike fork added to a street bike frame.

Are you presuming the swing arm is horizontal? How would we allow for it if it's not?

If you know of "sweet spot" for rake and trail for different types of bikes and riding, that could also be helpful to add, for those of us trying to a performance improvement instead of just appearance improvement.
5. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
Important note - I've updated the app enough that I actually changed the file name, and may do so again in the future. I'll edit the first post here to get rid of the obsolete file (it actually spit out wrong numbers in some cases). I am keeping a list of the most recent version(s) on the index page - https://sebwiers.github.io/motorcycle-front-end/

The swing arm position determines the stance of the bike, but that is accounted for when you enter the known wheelbase, neck position, and rake. Its is assumed that the relationship between the rear axle and neck does not change (other than as entered in the inputs for chop / neck out / neck up) when you swap the fork or put on different sized wheels, so the swingarm can be anyhow you like (or it could be a hardtail) as long as its not changing.

The new version has a list of sample bikes you can load that each show a different sort of mod, to make it clear what those do. Also, re swingarms, I added a feature that lets you stretch / raise the rear end. So if you fit longer shock, for example, you can just bump the rear end up by however much the resulting lift is. In such a case you would actually use a negative number for the "rear up" - the number is how much the axle moves if the frame is in a stand held by the engine. That may seem to go against what I just said, but the point is it is a special exception to the "relationship between the rear axle and neck does not change" rule that needed to be coded in.

That's effectively how all the math works as well - it runs the numbers as if you had locked the engine in place (say in a frame jig...) and draws outwards to the axles using the entered figures, then figures out where the contact patches are (based on wheel size) and does the other math (like distance between contact patches = wheelbase). This is very clear if you tic the "hold on engine" checkbox, and in fact all that box does is turn OFF the code that levels the drawing of bike (which isn't even done by computing co-ordinates in my code, I literally just rotate the picture before displaying it).

For normal bikes with normal telescopic forks, a sane starting point for trail is 3-5 (75 to 125mm) inches. 100mm is what I started at with my custom Hossack setup, and it was only after finding it difficult to turn while braking (because there's no brake dive to shorten the trail) that I went to a smaller number. I've heard tell of good handling bikes all through the rake range, from 0 to 50 degrees, and all through the trail range, from 0 to 12 inches!

I'm beginning to suspect no single "sweet spot" really exists, or at least that handling effects (even simple ones like stability and nimbleness) are more complex than just those two numbers, especially if you start doing weird stuff with wheel path (like a Hossack setup or girder / springer does), anti-dive, tree rake (which again change change wheel path), wheel size, etc.

In the end its down to personal taste and suitability for application. I'm not an experienced off road rider, so won't make any predictions about off road setups. However, my sub-20 degree, 65mm Hossack setup handles choppy surfaces at high speed AMAZINGLY well...
boatpuller and Pezz_gs like this.
6. ### Pezz_gsCant ride for crap

Joined:
Nov 13, 2004
Oddometer:
4,565
Location:
Sydney Skunkworks
Great App Seb

I will be bookmarking that one for sure

I had wanted to make one myself, now I dont have to . . . . .

It would also be good to be able to solve for offest . . . . To give say '100mm' trail. Magical Number

So put a ? ina box to solve. I see you one can toggle up the measurements on the boxes
7. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
Thanks. Out of curiosity, why were you planning to make one? Aside form the obvious engineering curiosity, I'm doing it partly to build my project portfolio up (I'm a web developer) and because I want to gain the skills (math and programming) needed for similar projects that will do more advanced calculations (like front end kinematics). Though I'm starting to suspect I'm gonna be hitting a performance wall with that, given the draw speed here. If you still feel inspired to make your own, feel free to rip mine off; the code is on github, isn't minified or otherwise obfuscated, and includes a GNU license in the comments.

Solve for offset? You mean the user inputs a desired trail on the stock setup, and it fills in the required offset? That's pretty simple math once you know the rake, neck height, and tire diameter, but the user interface would get clunky (its tricky to have multiple fields where the user has to fill "all but one"). Maybe its the sort of thing that could work well as a pop up form. There's also good reason to include some help pops ups, etc. But ergonomics like that are time intensive; I've been throwing my brainpower at the harder math (and still have a couple important numbers to pin down).

The number toggling is an automatic feature of modern browsers; the HTML code just specifies the input type as "number" and the browser handles the rest. Didn't take any more work on my part, and I'm not sure if every browser does it. I suspect most that support HTML canvas (the drawing method I used) do.
Pezz_gs likes this.
8. ### cycletlhSlower than yesterday!

Joined:
Mar 10, 2006
Oddometer:
133
Location:
Spokane, WA
This is a very useful tool. I have an interest in building a street tracker. With this, you could put in donor bike dimensions and then make changes to get the proper rake and trail. It would also help in fork selection.

I use a similar type program to calculate circle track front suspensions for race cars that was developed by Performance Trends. In addition to the description they also have an alpha character designated to the dimension. Both a thin line and an alpha are shown on the drawing. This makes it easier to visualize and provides a working print. It appears that all dimensions are from neck bottom which works.

You are correct in that all angles are based upon the bike sitting on a level surface. Simply raising the neck height changes the neck angle and corresponding numbers. Thanks
9. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
Yep, that's a pretty good summary of what its useful for... wheel change sizes too, obviously (mostly applicable for the Sumo and Chopper guys, though I'd guess some ADV rider also switch up wheels).

By "alpha character", you mean numbers written in on the diagram? I could work on that... problem would be which ones to show, and to avoid getting busy. You are right that dimensions that key to the neck are all from neck bottom. I use the term "crown" because that's what its called on a bicycle; the lower head tube bearing race is the "crown race". The exact point used in the calculations would theoretically be the center of the race / head tube.
10. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
I updated it so that the URL has a hash appended that encodes the inputs. That means you can bookmark / share links that describe the setup. This is a necessary pre-step to making user-savable setups, collecting stock frame data, etc. Also it matches the altered groundline properly now (in most cases anyhow - there still seems some weird edge conditions when wheel size differs hugely or is close to wheelbase).

Example: https://sebwiers.github.io/motorcyc...8bCHOP2.5bFL15bFTO1bFAO1bRT0bNO0bNU-2bRO0bRU3
11. ### cycletlhSlower than yesterday!

Joined:
Mar 10, 2006
Oddometer:
133
Location:
Spokane, WA
This is what my race car program looks like:

http://performancetrends.com/rc.htm

The individual points are lettered in the diagram as that is what they pertain to. As an an example on yours a line from the crown to the ground would be a helpful visual and easy to reference if it had an associated letter. Dimension A, B, C, D, etc. Not really necessary as you provide the dimension in the chart.

My race car program allows me to see what the suspension is doing as it moves. I use this to design a new chassis that does what I want it to when the suspension moves. A motorcycle is much simpler.

Once again, thanks for developing this.
12. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
Hmm, yeah, I think I've got few enough numbers going on that I don't need labels, but I could add lines. I could also do something like, when you mouse over the field, a line appears / is highlighted. Unfortunately the tech I went with (HTML canvas) doesn't easily support that, its looking like I should have gone with SVG or some other option that makes the lines actual page elements instead of just drawing pixels. Then again, lots of video games use the canvas and obviously have interactions.

I was actually inspired to try this as a web page by https://www.racingaspirations.com/apps/suspension-geometry-calculator/
13. ### IronforgeAdventurer

Joined:
Aug 10, 2011
Oddometer:
90
Location:
Macedonia
Thank you for the effort of making this free software or tool.
Usually i do it manually in the jig. This will save time if i can do it on the comp.
My only suggestion is to make the software more simple and user friendly!
For me personally as custom bike builder, most important is the trail on the front axle. Cause we all want our bikes to handle as best possible.
I am subscribing on this topic!
14. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
23
Location:
Saint Paul, MN, USA
Thanks. Setting up physical bike parts before doing work is still important once you find numbers you like; my tool can't show if you'd have issues with something like the wheel being close to headers, bars hitting the tank when you turn, etc. Not to mention general aesthetics.

"Simple and user friendly" is very hard for me to judge - as the programmer, I know exactly how it works, so everything seems simple. I've tried my best to make functions obvious if you play with them, but am open to specific suggestions. I've reached the point where is has 99% of the features I'd planned and is (as best I know and can tell from the drawings) doing all the math accurately, and can either re-work the code to make future features easier, or focus on user interface improvements. Improving the UI is hard without specific suggestions, but I'm guessing something like a help button next to each field explaining its purpose might be good?

Trail is one of the calculated fields, is there maybe some other way it should be used / indicated? Would it be worth drawing a line segment in the diagram that corresponds to the trail? (I just went ahead and did so, since it doesn't hide any other lines.)