moorepants / bicycleparameters Goto Github PK

The raw data text file for the 'Rigid' bicycle does not contain a value for the 'lamst' field required by the method bp.rider_on_bike().

rigid.add_rider('Jason', reCalc=True)
There is no rider on the bicycle, now adding Jason.
Calculating the human configuration.
Left arm's actual position does not match its desired position on the bike's handlebar. Left arm actual position:
[[ 0.76204482]
[-0.27266064]
[-1.10340464]] .
Left arm desired position:
[[ 0.68981424]
[-0.2675 ]
[-1.1186071 ]]
Left arm base to end distance: 0.581688096145 , Left arm D: 0.518569971695
Right arm's actual position does not match its desired position on the bike's handrebar. Right arm actual position: [[ 0.76204481]
[ 0.27266071]
[-1.10340466]] .
Right arm desired position:
[[ 0.68981424]
[ 0.2675 ]
[-1.1186071 ]] .
Right arm base to end distance: 0.581688096145 , Right arm D: 0.518569971695

Try out the TMS bicycle and I have some divide by zero issues.

Maybe a global needs to be set with respect to the pathToData so that all this extra data I create does there instead of the current working directory.

We need to drop support for versions earlier that 1.2.0 because there are errors in the yeadon code.

try it with a clean install

On mobile devices and smaller screens in general, there are a few changes that need to be made in Bootstraps for it to display nicely.

• Navbar has 3 line menu option despite not containing any hyperlinks. Hyperlinks to parts of the page should be added, or more likely, the menu 3 line box should be removed entirely
• The eigenvalue slider displays in between the first datatable and the other two. The slider should move to be on top of all of the datatables with the other options
• Possibly center or reposition the reset button and plot display options alongside the eigenvalue slider for mobile devices? They work as is, but it could be nicer if they were neatly aligned.

Here is an image using inspect element for the iPhoneX. I didn't see the 3 bars on the navbar, but I'll take your word for it Jason.

The eigenvalue plot has data for multiple lines plotted against the independent variable (speed). There are four eigenvalues and each have real and imaginary parts. So you want to be able to download the plotted data in to a CSV file that looks like:

speed,eval1_real,eval2_real,eval3_real,eval4_real,eval1_imag,eval2_imag,eval3_imag,eval4_imag
3.0,x.xxx,x.xxx,x.xxx,x.xxx,x.xxx,x.xxx,x.xxx,x.xxx,x.xxx,x.xxx

The x.xxx should be values printed to 14 decimal places using '{:1.14f}'.format(eval1_real).

This function calculates the eigenvalues: https://github.com/moorepants/BicycleParameters/blob/master/bicycleparameters/main.py#L853

JBike6 can do this and it is bit more intuitive to a user. We should support this method in addition to the current method.

Things that need to be done:

• rename cycle_app.py to app.py.
• Add entry point for the app.
• get it working on Python 3.10 (including Yeadon)
• Autodoc the new models (or make them private for now)
• Complete all docstrings of the new modules
• Decide to lock in the new module API or make the modules private for now
• Improve and update the app colophon

Removed TODO.rst from the repo and moved the notes here:

• Add the root loci plots in the complex plane.
• Add a transfer function method to the Bicycle class.
• Start using some other convention other than camel case for the file names.
• Add a critical speed method to the Bicycle class.
• Add methods to ouput other parameter sets (Sharp2008, JBike6, etc).
• Change lsp + lst to just one variable for the bike geometry.
• Move some of the functionality to DynamicistToolKit and have the imports work with uncertainties.
• Add a load_parameters method to the Bicycle class.
• Add lots of tests for the code.

I added a Child sized person to sit on the Gyro bicycle. The current code to set the shoulder angles does not work for the child.

Check this branch 37df2b2

I have much better code for picking these angles in my dissertation that solves 8 non-linear equations to lock the degrees of freedom and force the arms to hang downward: https://github.com/moorepants/dissertation/blob/master/src/extensions/arms/arms_holonomic.m

This needs to be implemented in BicycleParameters with respect to Yeadon's coordinate system.

If you add a print statement in cycle_app.py where plot_eigenvalues is called and refresh the app, you see that print statement displayed 3 times. For some reason that callback is executed too many times. If you change the bike selection it them seems to execute 4 times. These callbacks should only be executed once per change of any input box and ideally once per load.

@sandertyu

The hands are not being correctly placed onto the bicycle's handlebars; specifically the right arm. This was initially a problem only for the Stratos bicycle, but also has occurred with the Browserins bike (did not check all bicycles; going to sleep).

Running from windows terminal on my system, the cycle app appears as so:

It also does that jarring screen move effect whenever the eigenvalue slider is change. We had fixed this before on past versions. You can also see that the eigenvalue slider is not readable, which is what I had mentioned in the pull request.

However, when I run through my linux subshell, the app appears correctly, the same as it does on the live version. Here is what that looks like;

I've done conda update --all, and each of my packages should be equivalent across my windows and linux versions of python. I have no idea what could be causing this. For now, I'll just run through the linux subshell.

As per the suggestions from Bryn Cloud, we can go ahead and change a few things

• Remove the title underline and embolden it some other way. The underline can be confused for a hyperlink
• Include documentation hyperlinks for the version control box in the lower left hand corner. I'm not sure how to dynamically access these documentation pages, as I feel the url may change over time or as new versions are released. If anybody knows, please let me know.
• Add a link to this repository

Check if the rider's legs and arms are too short and throw error/warning if so.

When a cell is selected and hovered over, it appears as so;

However, when the cell is selected and you do not hover over it, the pink background disappears and the text becomes very difficult to read

The culprit CSS is right here. If the color value on the right where the arrow points is changed, then the text color will change. I've tried multiple ways of directly putting this CSS into our styles.css file in assets, but it does not good.

My goal is to remove the pink background, leave the border, and have the text be white and legible as it normally is. It would look like this. It is much nicer this way because there isn't currently a method (as far as I know) to unselect a cell, so the default pink border is far less obnoxious than the entire cell background changing.

In the Dash documentation, in the section about the dark theme, when you click on the cells of their table the text color does not change. My dark mode styling is identical. I guessed that the bootstrap theme was overriding something, but changing the theme does not fix the issue. The text color changing when a cell is selected also existed before bootstraps was even implemented within the app, so there's something hidden going on.

Andrew Dressel had this comment:

"Will you implement some kind of "About" or "Help" functionality in the UI? For example, How it steer axis tilt measured? It certainly is discoverable, especially if you switch to degrees, but some users, especially the old ones, might prefer just to read it explicitly."

We need to explain the parameters and the outputs more carefully so the app is self contained.

RIght now Model() takes a dictionary but that means you can't use any functionality of ParameterSet() inside of Model().

The app will work more smoothly if we create the figure once and then only update the data in the plot when the widgets are manipulated by the users. Check out how the skijumpdesign app does this (starting around here: https://gitlab.com/moorepants/skijumpdesign/-/blob/master/skijumpdesign/app.py#L1107)

For some ot the bicycle/rider combinations the hands and feet are not placed within machine precision, sometimes only to milimeter accuracy.

Two examples:

import bicycleparameters as bp
rigid = bp.Bicycle('Rigid', pathToData='data', forceRawCalc=True)
rigid.add_rider('Jason', reCalc=True)
rigid = bp.Bicycle('Rigidcl', pathToData='data', forceRawCalc=True)
rigid.add_rider('Charlie', reCalc=True)

If you only define the geometry needed for configuring the rider in the measured parameters input file and want to use a bicycle that only has the benchmark parameters explicitly defined then you have to use Bicycle(... forceRawCalc=True) to make the measured parameters evident for the rider configuration calculations, but the program fails because it then tries to compute the benchmark parameters but there are no measured parameters defined.

Possible solutions:

1. Put the rider configuration parameters in a different file so the forceRawCalc=True flag isn't needed when creating a Bicycle object.

Eigenvectors can only easily be visualized for a specific speed and eigenvalue set. It would be nice to have a slider to adjust the speed and the eigenvector component plots update interactively. See the eigenvector plots I make here for some ideas: http://moorepants.github.io/dissertation/eom.html

Users should be able to construct a yaml file with all the bicycle parameters and upload it to the app.

The App currently appears differently depending upon which browser you view it in. I've only tested it in Edge, Firefox, and Chrome, but Chrome seems to be the outlier where it appears as I have intended it. I believe the fundamental issue is that the font sizes within the datatable are changing in each browser, because the text does not wrap in Chrome but in Edge and Firefox it does. Chrome has a smaller font size than the others, but this difference only occurs within the datatable and not within the information section further down in the page.

(how it appears in chrome)

(how it appears in edge)

I've even tried changing the dash version from our current 1.12 to the most recent 13.4. While this version is stable and works fine with our app, it does not solve this issue.

The purpose of this is to update the datatable presentation based on the feedback we've seen so far. I'd also like to brush up on a few stylistic things in general. Here's what's planned to get done;

• Fix the datatable background color so the values are viewable in night mode and against the dark page background
• Move the Parameters table to be on top of the 4 main body tables
• Change the title of contextual parameters to just 'parameters'. Other suggestions are welcome
• Make the label column uneditable
• Add units to all the labels
• Format initial table values with proper sig figs
• Display steer axis tilt in degrees rather than radians

Feel free to comment on other suggestions. It's annoying that table values cannot be edited digit by digit at the moment, I plan to see if that can be fixed at some point.

@sandertyu You probably have some or all of these already in your head, but here are my initial thoughts:

• Each parameter needs units beside the name, like Radius [m]
• Each parameter value should display a reasonable number of significant figures. We need to decide on them, but distances probably only down to mm masses maybe 1/10 kg, etc.
• The width of the parameter table should have a fixed width that leaves minimal horizontal space in the cells.
• The table should be left-right centered.
• The figures should be left-right centered.
• We should choose a color scheme with 3 or 4 colors and stick to that for all elements. You can use sites like: https://mycolor.space/
• I don't see any need for the dark/light mode once we pick a color scheme.
• The bicycle selection box needs a title like "Select a bicycle:" above the box.
• Bicycle selection box should have a fixed with.
• Make the bicycle geometry plot on the left and eigenvalues on the right. (we could also think about addind the bode plot too)
• It seems to work fine for mobile sized screens now, which is good.
• Steer axis tilt should be entered in degrees instead of radians.
• We need a better name for the app. Some ideas:
  • Bicycle Dynamics Analysis App
  • Linearized Bicycle Dynamics
  • Bicycle Parameter App
  • Bicycle Dynamics Design App
  • JBike7 (would have to ask Andrew)

Need to find a new way to host the app:

https://blog.heroku.com/next-chapter

The caster line (lower blue one in this plot) often makes the lower y limit very large and the more interesting parts of the graph are not shown. It would be nice to both have a better default limits (maybe -10 to 10 would suffice for most bikes) and helpful to allow the user to change the limits. We change the x limits via the speed slider. We could add a slider for the y limits or maybe simple text boxes are enough. Here's an example of a plot that isn't zoomed like we want:

But fixing #78 would allow the user to dynamically zoom, so that is a better long term solution for changing the axes.

the eigenvalues are not being computed correctly

The plan is to give the user the ability to turn on/off the center of mass and inertia ellipse drawings on the geometry plot:

• Add a checklist component for user selection
• Format the component within its visual context
• Add/edit callbacks to redraw the geometry plot with new keyword parameters as the user selects a checklist option.

Here is what it currently looks like on a wider resolution. I want to get the top edge of both EigenValue slider and the Display Options to be at the same level. When the resolution shrinks, they stack on top of eachother like the plots do (which is good).

Some of Andrews comments:

• it doesn't seem possible for me to edit the existing number, to tweek a just a digit intead of replacing the entire number
• It seems that I can click on and edit the row labels, such as "mass", and "radius", but I suspect that the program does not read these changes. I cannot edit the column labels

Right now the feet are pointed along the leg and the tip of the toe is constrained to the bottom bracket axis. This makes the knees sit up too high and doesn't represent the foot inertia well.

First idea (more work):
Make the foot bend at the ankle at 90 degrees for the bike configuration and constrain the bottom of the arch of the foot to the bottom bracket axis (or the ball of the foot)

Second idea:
Don't bend the ankle but constrain the foot at the heel center (or something appropriate) to the bottom bracket axis.

It makes the distance from the shoulder to the grips too long, longer than his arms. Maybe this is an error in the measurements for the handlebars which were done at a later date than the somersault measurement.

Thought lets collect small documentation mistakes while going though the documentation:

• In example.rst >>> bicycle.parameters['Benchmark']['mB] = 50. misses an '.
• In data.rst it says two times <rider name><bicycle name>YeadonCFG.txt. The second should be <rider name><bicycle name>YeadonMeas.txt if I'm not mistaken.
• The reference to the raw data sheet reference in data.rst does not work anymore.

We should develop a custom Plotly based figure (like in the skijumpdesign app) or convert the matplotlib lib figure to a plotly figure or use some other JS based output (matplotlib can produce SVG, and JS backed figures, or Bokeh, altair, or other).

Just saw this:

https://github.com/plotly/dash-alternative-viz

Might make it easy to turn the Matplotlib plot into a JS figure, as opposed to switching to plotly.

As I mentioned in issue #46 , there are a couple things to be solved. The method needs to be able to identify and select between 2 different cases:

1. The callback is fed a steer axis tilt in radians from the default app-data bicycles. This isn't too difficult, I can just selectively convert the value to degrees and insert it that way.
2. The callback receives that there is user edited data, and it has to receive the value in degrees, convert to radians to recalculate, and then go back into degrees like in case 1.

Functionally, we need to be able to determine whether values are being received in radians or degrees, and then do the conversion in case 2 as necessary. It may be easier to add functionality in bicycleparameters to accept degrees, but otherwise, how could we solve this?

@moorepants

The purpose here is to integrate and replace my current CSS with that already written in Dash Bootstrap Components. The main benefit is using its layout features, so elements can be positioned easily and in ways that I don't know how to program myself. Secondly, there are a few components in the Dash Bootstrap Components library, such as button, which can essentially replace current components while looking a little nicer. The main goals are as follows;

• Use bootstrap layout in order to organize the web elements.
• Replace a few current components with the bootstrap counter-part (this is often as easy as replacing module html with dbc).
• Choose a theme for the app. Currently my favorite is Slate, but the rest can be navigated through by the "Themes" toolbar at the top of the linked page.
• Fit everything on to one screen page. This may be a stretch, but it should be possible, especially now that the CSS is easier to work with.

There are better inertia plotting methods in the new-api branch that should be applied to the web app. These show the radii of gyration and it looks much better and is more useful.

This should likely use the eigenvectors as more proper predictors of the modes. There is the issue that extreme bicycle designs may not have the characteristic weave, capsize, and caster modes though.

Some funky errors are happening due to this and the figure isn't saved. I've commented it out in commit b807203