# 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:
91
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. ### SalsaLong timer

Joined:
Dec 12, 2006
Oddometer:
1,035
Location:
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:
91
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,590
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:
91
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,724
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:
91
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:
139
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:
91
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:
91
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:
139
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:
91
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. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
91
Location:
Saint Paul, MN, USA
The motorcycle front end setup app / web form I'm working on is coming along, and I've hit a phase where I could use some help from people. You don't need any computer skill, just a (stock) bike and the ability to do some (accurate) measurements. If you have a modified version of the same bike, or can give accurate stock numbers for you chop, that's even better - I can use both in the same form to show the difference between the two.

The idea is that when you go to my web app and enter bike geometry numbers, the URL changes to reflect those numbers. No, this data isn't sent to my server - its a purely local change to the part of the URL at the end after the #. The idea is to allow users to bookmark the page when they have a setup they like, which "saves" that setup. But they can also share that URL as a link so that others can see the setup data. And that exactly what I am asking people to do - fill in the data and share a link, along with a description of what bike the data is for. I'll take as many as I can and jam them into the drop down list to replace the cooked up examples I have. I can even give you credit if its your custom build, with a custom table title like I did for the current selections.

Eventually I'd like to have some sort of back-end data to make it possible for users to share stock data and other setups so it can build up a good database of numbers for stock & modified bikes without any direct involvement on my part, but that would have a lot of the same issues you get with a web forum / other social media (mostly how to weed out bad info and give people the option to find what they want and ignore the rest).

Below is an example of what I'm looking for using my own build. I measured in CMs, but you can give the measurements in any units you like. To enter your own numbers and get a link, go to https://sebwiers.github.io/motorcycle-front-end/planner_001.html - an example will load up, but when you alter it, the URL will change to one that reflects your numbers.

Stock model: 1981 Yamaha XJ750rh SECA
Modified name: SECApocalypse
Units: Centimeters

Joined:
Aug 10, 2011
Oddometer:
91
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!
15. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
91
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.)
16. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
91
Location:
Saint Paul, MN, USA
Kept chugging on my motorcycle geometry planner, got the kinks ironed out that sometimes resulted in drawings where the old / modified bike didn't line up correctly etc.

More usefully, I added the ability to "save" setup to the drop down list. That list is 100% customizable - you can also delete items from it.

Hope its useful for some, and as before, I'd love to see links to setups for common stock donor bikes so I could add them to the options list that people start off with (currently its completely empty). Not sure how much time I'll be giving it in the future because I got a job and I generally work on bikes instead of code when I have money (and to avoid bringing my work home with me).

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

17. ### cycletlhSlower than yesterday!

Joined:
Mar 10, 2006
Oddometer:
139
Location:
Spokane, WA
Looking good! The line from the neck bottom to the bottom of the tire, is that dimension your Ground to Neck Bottom? As a builder I would like to see Ground to Neck Bottom perpendicular to the ground. This allows me to set up the jig based on the design from your program.
sebwiers likes this.
18. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
91
Location:
Saint Paul, MN, USA
I... don't know? I'll see about getting that sorted today. Bugs happen, and its great to get reports of confusion / likely errors.

I'm not sure why the distance from the neck bottom to the front contact patch would ever be relevant in this context, so I'm pretty sure that is NOT what I intended to put in that field, nor would the figures make any sense if it was. I believe"Ground to Neck Bottom" is actually the value you are looking for (vertical distance) and my "front axle to neck bottom (vertical)" distance is in fact the direct distance from the front axle to the neck bottom, so is not (or only very rarely) vetical.

That makes sense as a single simple error - the "(vertical)" after "Front Axle to Neck Bottom" should not be there, and should instead be placed after "Ground to Neck Bottom".

The obvious solution to this quandry is to actually draw the dimension lines (maybe in dotted style) and label them, which I did do in some cases for debugging purposes (specifically, drawing the contact patches to be sure I was getting the wheelbase / rake / frame rotation correct).

Unfortunately my code is not structured to make that easy - I really need to go back and refactor as proper object oriented code so that I can simply trigger a "draw" function for an individual part or dimension, rather than having a massive "draw bike" function that extracts all the dimensions from the bike data and renders the image. I'm not sure that's really viable for the HTML Canvas though - I'm considering that maybe I should have used SVG. I'll probably truck on with the canvas for now, and switch over to SVG when / if I start work on something that is intended to handle kinematics, so has to show parts moving relative to each other.

Despite doing it for a living for 6+ years now, I'm a pretty novice programmer. I'm fairly good at translating real world concepts into math & code, but pretty bad at structuring code more complex than a handful of functions. That tends to be how it goes for self taught programmers, and even CS schools don't do a good job teaching it. I just landed a job where I hope to get some good mentoring and work with design architecture - up until now, none of my employers have really done code reviews, aside maybe from running automated style compliance tools that ensured lines were properly indented etc.
19. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
91
Location:
Saint Paul, MN, USA
I think the "front axle to neck bottom" value is as useless as "neck to contact patch" for any actual construction purpose, since it is not in line with the rake, or vertical, or any known angle. Its maybe useful for determining if a tire will fit, but the tire fit also depends on specifics of fork construction, such as how thick your lower triple clamp is and how much travel you have. I'm gonna just cut it out to save space. Is there a value that should replace it?

Also need to do some work getting the image to stay 100% on the canvas. As wheel sizes get larger relative to wheelbase, the bottom of the wheel (and so the line for trail, etc) gets pushed off. This doesn't seem to be a problem for realistic motorcycle dimensions, but when you go to bicycle type values (which have shorter wheelbase relative to wheel diameter) it is.
20. ### sebwiers

Joined:
Aug 2, 2016
Oddometer:
91
Location:
Saint Paul, MN, USA
Deleted that pointless field, drew lines for the the ones that I still have. I can't really do labels because of how I calculate and draw things; they would all be upside down.