This is an Atom formatted XML site feed. It is intended to be viewed in a Newsreader or syndicated to another site. Please visit Atom Enabled for more info.

Guardian Article: http://www.guardian.co.uk/science/2012/nov/18/cycling-parkinsons-wellcome-prize-catherine-hess

Welcome Trust Blog: http://wellcometrust.wordpress.com/2012/11/19/as-easy-as-riding-a-bicycle/

Reddit: http://www.reddit.com/r/science/comments/13fage/as_easy_as_riding_a_bicycle_insights_into_how_a/

]]>The Explorer I Anomaly

by

David A. Levinson

Lockheed Martin Space Systems Company

UC Davis Mechanical and Aerospace Engineering Seminar

Date: 15 November 2012 Thursday Time: 4:10-5:00 pm

Abstract

On January 31, 1958, the United States Army Ballistic Missile Agency successfully launched America's first satellite, Explorer I, into orbit around the Earth. As is well known, not only did this achieve the political goal of putting the United States back in the space race it was losing badly to the Soviet Union, but instruments onboard Explorer I sent back the first data revealing the existence of the Van Allen radiation belts -- a major scientific triumph. What is not so well known is that Explorer I also made its mark in aerospace engineering lore by exhibiting an attitude motion anomaly that none of the extensive published literature from the previous two centuries of research on rigid body dynamics had accounted for.

During this talk, the anomaly will be described in detail, and, through the use of modern-day dynamics simulation tools, including animation, the principles of mechanics underlying what happened will be discussed in terms suitable for a general audience. The consequences for later spacecraft design from what was learned from the Explorer I anomaly will be explained.

About the Speaker

David Levinson currently holds the position of Senior Staff Research Engineer at the Lockheed Martin Space Systems Company, based in Sunnyvale, California. Most of his work has been in the area of dynamics of complex mechanical systems, such as multibody spacecraft, robotic devices, and aerospace mechanisms. Over the years, he has been the recipient of numerous engineering awards, among them the American Institute of Aeronautics and Astronautics (AIAA) San Francisco Section Engineer of the Year Award in Astronautics, the American Society of Mechanical Engineers (ASME) Santa Clara Valley Section Distinguished Mechanical Engineer Award, the American Astronautical Society Outstanding Achievement Award, and the Lockheed Missiles and Space Company President's Award. He has numerous journal publications and is a coauthor of two McGraw-Hill textbooks -- one on Spacecraft Dynamics, and the other on Dynamics: Theory and Applications. He also coauthored three desktop-published textbooks on Dynamics. He is a Fellow of both the American Astronautical Society and the ASME, and is an Associate Fellow of the AIAA.

Hi, I'm Jason Moore from UC Davis. I've been working on bicycle dynamics problems for quite a few years now. I've spent most of my time trying to create models of the bicycle/rider system from experimental data. In particular understanding the system open loop plant and the closed loop control by the rider. I'm not going to go into much detail about my research today, it can be found at biosport.ucdavis.edu if you are interested in the research findings. I want to spend my ten minutes discussing some of the ideas and thoughts I've gathered over the years about what needs to be done to advance research in our somewhat small field. These ideas may very well be applicable to science in general, but I'll focus on the relevance to the subject area. I'll start with a couple of notes that reflect the technical side of things and follow with some general thoughts on the state of our research practices.

I'm not convinced that we have realistic enough models of the vehicle (which may or may not include the passive dynamics of the rider). This is especially true of the bicycle and probably even true of the motorcycle. The bicycle data I've collected clearly shows that the Whipple model is deficient in modeling the input steer torque to response relationships. On the other hand, the motorcycle folks have significantly more data to back up their models, but we still have relatively little data to have strong proof of the validity of these open loop models. For the Whipple model, the most likely culprit is our poor assumptions about the tire/ground interaction but the effect of the rider's biomechanics also plays a large role in the bicycle's response. We need more data to prove which models are good predictors.

Engineering is infamous for just showing the best plot in papers. I'm not sure why we collectively accept absolutely no statistical significance for our published results time after time. Our sub-discipline is highly at fault for this. The number of papers I've read with no stats ashames me (including mine!). When are we going to catch up to the rest of science? The data driven approach with proper statistical analyses is the new norm in other sciences, engineering should be no different. We have to set a higher bar in our reviews to encourage more data with more proof that our models are realistic predictors. n=1 is no longer acceptable.

Humans are the ultimately complex machine and their role in typical single track vehicles is great. Strides in understanding the human will start to unlock some of the important questions we are all after including the link to the system's properties and the vehicle handling. We've recently published a paper in IEEE Systems, Man, and Cybernetics that touched a bit on how we may assess task independent handling qualities of different vehicles analytically. But this method requires a realistic model of the human's control system and response to error. Better characterization of the human is the only way to understand what handling qualities are.

But I'd also like to point out that the view from the control systems perspective is too narrow. The human is a highly variable and adaptive controller, not to mention that it is one of the most complex "machines" we have to study. For example, we are able to quickly tune our control strategies when given different bicycles and motorcycles, but we also perceive changes to vehicles if the correct stimulus is provided even though no relevant changes were made to the vehicle. The complexity of the human as a controller spans many fields:

- Psychology (cognitive, psychophysics)
- Physiology
- Neuroscience
- System Identification
- Control Systems
- Human Factors

We need to build connections and collaborations among these fields to make solid headway in understanding human response while operating a bicycle or motorcycle. These collaborations with an increase in experiments and data collected human response under controlled and uncontrolled conditions for a variety of typical maneuvers is desperately needed to start to create and validate realistic human control models.

Now, I'd like to touch on some topics that are very interesting to me. I've had my finger on the pulse of open science for some years now. I'd like to see the bicycle/motorcycle dynamics community to embrace open science practices to encourage faster development and reproducible, reusable research.

We need to share data and we need to produce a lot of it. Lets turn the single track vehicle problem into a big data problem. This means putting highly detailed and documented data into public repositories and embracing the emerging idea of Data Papers (i.e. writing papers strictly about high quality data along with publishing the data so it is easily reusable). Sharing our data and developing some standards in data formats and types would allow us to more rapidly generate models, validate models, and verify the that our models can predict a large amount of data from a variety of motorcycles and bicycles.

We all measure the dynamics of vehicles and the physiological data of human riders. I'm envisioning a common data repository with these measurements collected, documented, and detailed for easy querying and retrieval. I'd like to have the ability to dream up a new model and validate it against hundreds of data sets one night while I'm sleeping. Or use hundreds of data sets to generate or identify a model with machine learning techniques or system identification. As it stands now, we all collect our own tiny set of data and use it with our models. But as a whole we hardly know if our models predict other datasets. Many fields such as genetics, ecology, astronomy, climate change, etc have embraced big data and their predictive ability reflects it.

Let's create a repository that is widely usable.We data from more fully instrumented (kinematic and kinetic) vehicles with human isolation and human in the loop from a variety of vehicles to provide rich datasets. Tire data is also a big missing piece of the puzzle. Psychological data too.

The more we can fill standardized, publicly accessible databases full of rich, quality data, the ability to synthesize and create data driven models becomes real. I believe we need to stop tyring to make your model fit the data and start letting the data create the model. The system identification and machine learning communities are at the forefront of this. Sensors are cheap, data is cheap let's flood our space with good data that is reusable by others.

If we open up our data for the sake of advancing our collective research, what about the software. Why do we all write our own hidden proprietary code? Are we ashamed to show the internals? How confident are we that it is bug free and is correct? Software should be just as open as the equations in our papers. We need to know that the software we are using is producing correct results and we need to have the ability to hack the code. Secondly, why do we all write our own software? Why can't we work together on a large meta software package for bicycle/motorcycle dynamics that has a variety of models, benchmarks, control system implementations, and have it linked to an open repository of data? The collective work of our small but talented group could make a software project that puts FastBike, VehicleSim, and JBike6 to shame. Some of the most innovative disciplines are doing this. The machine learning community is a prime example, so is astronomy and many genetics projects. It makes no sense for us all to continue to write our own versions of the same code everyone else is writing when code reuse is to our advantage for reproducibly, productivity, validity, and minimizing bugs and errors. The computer science world has made all of this relatively easy. The tools are there, we only need the will.

The bicycle and motorcycle literature is actually still manageable. The entire number of bicycle/motorcycle specific papers is somewhere between 500 and 1000 papers. The number of papers has been growing significantly in the past several years. Why don't we have a central repository that is collectively maintained? There are numerous modern software solutions that allow this kind of thing. The time has passed when we all maintain our own reference databases, this is something that is ideal for crowd sourcing and as the papers increase in number it will be the only option.

Very few of the experiments in our field are explicitly reproduced and I'd guess that many of them can't be reproduced. It is well known now that much of science is not actually reproducible. I'd like to see some of the important works from our literature base be reproduced with modern experimental techniques to see if the results hold water.

Review papers.

With our literature base growing closer to 1000 papers we need to spend some time working on more meta papers. Deep analysis and review of the collections of work on vehicle identification, control design, etc need to put into a holistic context so that we can start to believe in the validity of various models.

]]>We opened up the sessions on Thursday with a special session entitled "The Future of Bicycle and Motorcycle Dynamics and Control" [original abstract, planning docs, handout]. Stephen Cain from University of Michigan chaired th first half in which five 10 minute lightning talks were given by Andrew Dressel, Ichiro Kageyama, Matteo Massaro, Dale Luke Peterson, and myself. They touched on robotic vehicles, full scale simulators, novel tire models, tire data collection, and tied these into the future directions of the research field.

Following the talks, Stephen and I facilitated a group discussion to develop a road map to future research directives. We started by having everyone in the room (some ~20 people) give their name and, in their opinion, the most critical/important topic(s) that need discussion. These were the identified needs:

- Consistent vocabulary, dictionary of terms so we can all talk the same language
- Rider control/robot
- Funding: it is really hard to get funding
- Community projects: lets have the best folks work on something collaboratively
- Less restriction in industry partnerships: allow us to publish
- Tire properties, quality data and models (where the rubber meets the road)
- Development and use of non-linear models
- Integration of controls with the rider's behavior
- Rider control during braking
- Differences in tires between motorcycles/bicycles
- Model and data sharing
- Quantifying handling qualities
- The need for more experimental data with human riders
- Work with the "green" communities for funding, both the bicycle and motorcycle are green transportation options
- Effects of central and peripheral fatigue
- Improve the "image" of bicycle and motorcycle research. Many don't understand why this is valuable.
- Clear model descriptions.
- How to assist human riders?
- How does this research relate to other fields such as manufacturing

After we heard from everyone we chose three topics to spend more time on: tires, the human, and community. We only talked five minutes about each due to my mistake of thinking we had to end at 11am instead of 11:30 (I apologize), but nevertheless we were able to get the conversation started on these topics. These were the notes:

- Is rim flex accounted for in the current models? It is especially relevant for bicycle tires.
- Tire behavior in dynamics tests.
- What are the temperature effects? The temperature is relatively constant inside the tire (in the air) but can get very hot at local points on the tread.
- Bicycle tires can have large effects

- What are handling qualities? Is there a definition?
- Are handling qualities independent of the human? Consensus seemed to be no.
- What is good performance for different populations?

- Online sharing tools
- Require standards for data exchange
- Need more opportunities to interact
- Avoid "group think"
- We may need to start an organization

These topics started conversation among the participants which continued throughout the conference. In the afternoon, Mont and I chaired the invited session on single track vehicle dynamics which included six 20 minute talks with questions and answers [proposal 1, proposal 2]. We had talks from Adrian Cooke (University of Twente), Stephen Cain (University of Michigan), Arend Schwab (Technical University of Delft), Matteo Massaro (University of Padova), Shintaroh Murakami (Keio University), and Jigang Yi (Rutgers University). The topics ranges from stability during braking and learning to ride to neuromuscular dynamics and controller identification. We had over 30 attendees during the session and some excellent talks. Matteo's talk was also selected as a semi-plenary talk where he was able elaborate to a larger audience later in the afternoon. Most of the relevant papers have been added to the Mendeley group.

We all complained about the lack of food at the conference (even for $500 fee), so we spent most of our social time together as a small group at various restaurants. My favorite part was floating in the Atlantic in the early hours of the morning chatting about research and such. Fort Lauderdale as otherwise a rich man's land with tons of cars and strip malls. Many of us rented bicycles and braved the roads and giant cars to get around, with one amazing late night ride through the rain. The conference organized the Jungle Queen boat (hideous) to take us around Thursday night and see the giant mansions in the "Venice of Florida". There were of course not enough plates and each person was only allowed to get one drink (even if you were willing to pay for it!). Nonetheless the bicycle/motorcycle conversations continued and plans started hatching for making a more formal organization. Shigeuro Fuji from Yamaha spoke on Friday (he was supposed to be in our session!) about measuring low speed weave oscillations in motorcycles and we all started packing up to head back to our respective homes. Stephen and Matteo went to the keys for the weekend and Arend made a trip to Miami before he went back home.

We worked hard one night on names for an organization. Some of the ideas are:

Acronym based names

- BAMDA: Bicycle And Motorcycle Dynamics Association
- BAMDACO: Bicycle And Motorcycle Dynamics And Control Organization
- IBAMDACO: International Bicycle And Motorcycle Dynamics And Control Organization
- BIMO: Bicycle and Motorcycle
- BIMODY: Bicycle and Motorcycle Dynamics
- STVD: Single Track Vehicle Dynamics

- RIDE
- ROLL

- control
- lean
- yaw
- trail
- caster
- rake
- non-holonomic
- Whipple
- hobby horse
- penny farthing
- camber
- slip
- thrust
- eigenvalues
- balance
- steer
- headtube
- pedal
- peg
- lance lost his stuff
- DOPE
- cucumber
- rally caps
- stability
- self-stability
- handling
- MOBI
- MOBIDY

These were more or less some start of the vocabulary we need to standardize to. We'd all had a few drinks after figuring this stuff out.

Andrew proposed some basic functions for the group which seemed like a pretty good set of goals:

- Arrange an annual conference
- Publish the proceedings
- Host a web site
- Host and moderate a discussion forum
- Host data and code for sharing
- Standardize vocabulary
- Somehow work to dispel myths and misconceptions about bikes in education and the media

And lastly a couple of fun things. This one presentation had the sexiest nude 3D model I've ever seen in an engineering conference NSFW!! :)

And I thought it was really amusing that the MathWorks booth was totally focused on Arduino. The reps talked so much about Arduino, you'd hardly know it was MathWorks. But when I asked one of the reps how they are contributing back to the Arduino community, he got defensive and said MathLab will NEVER be open source!! I don't think he understood my question. MathWorks is benefiting from Ardunio's success, as many others are, but most beneficiary's contribute back to Arduino (I hope) with code, support, funding, etc. MathWorks is sending zero of anything back upstream. Too bad. They'll soon learn that they will have to embrace open source to keep up with the Jones's.

All-in-all the conference was a success and I had a great time hanging with the few folks around the world that get stoked on our small but rad research topic. Hopefully we will all meet up again next fall for BMD 2013.

Jason

]]>

But that little story isn't what this post is all about. I also completed the longest thing I've ever written in my life that covers aspects of the work I've done since the beginning of 2006 on bicycle dynamics and control. I'm pretty happy with the result. I met several of my goals:

- Instant online open access publishing. I've used the Sphinx documentation system for web and paper publishing and released the text under a Creative Common Attribution license.
- Detailed documentation of all of my bicycle work. I was able to include the majority of the work I did over the past seven years.
- Reproducibility. Almost all of the figures, tables, and results can be reproduced with the included open source code (BSD licensed).
- Shared data. I've about gotten all the data cleaned up and shared publicly for reuse. If you can't find some particular data, then let me know and I'll dig it up and post it.
- Memoir. I've included prefaces to most Chapters that reflect on the history of the ideas, who was involved, and how the projects developed to put more "human" in the text than typical modern science writing.

All this was a lot of work, but I'm happy I pushed through it. My first git commit to the dissertation was on September 28, 2011 and I only took a break this summer for about a month and a half to go to conferences and do some traveling. So it took about nine and half months to put the dissertation together. This included a lot of data analysis for the System ID chapter and lots of polishing of previous years' work. I was able to focus solely on the dissertation by dropping all of my beloved extracurricular activities, but I struggled with eliminating casual internet browsing till the very end (probably my only addiction in life).

The final product in both HTML and PDF form can be viewed at http://moorepants.github.com/dissertation/ and the source code downloaded from https://github.com/moorepants/dissertation. Additional material can be found on this website (although some organization still needs to be done).

]]>

Edit: I rearranged things so it's actually at the bottom of the page now. Either way, it should be easy to find.

]]>

The source for the slides are here: https://github.com/moorepants/ExitSeminar

(Let me know if you want me to post the slides, otherwise I'm going to be lazy).

]]>

Anyway, a couple weeks ago I discovered that Blender, the open source animation software, has Bullet, an open source physics engine, built in. Blender has a handy graphical user interface for assigning the following properties for each body (and perhaps more that I'm omitting):

- Coulomb coefficient of friction - this is not truly a property of a single body. In the collision of 2 bodies, I believe that the higher coefficient is used.
- Elasticity - aka coefficient of restitution. Again, this is not truly a property of a single body. In the collision of 2 bodies, I believe that the lower elasticity is used.
- Mass.
- Mass center location.
- Collision detection method - this can be bounding sphere, bounding box, convex hull, triangular mesh, or several others. 'Sphere' is the logical choice for the ball; 'box' is good for the lane and walls; 'triangular mesh' for the gutters; and 'triangular mesh' for the pins. A mesh is not as accurate or efficient as using sphere-swept surfaces, but take what you can get.

Rather than go into the details, I'm just going to post a pretty animation here:

]]>

The identification of the linear dynamics of the bicycle can be formulated with respect to the benchmark canonical form realized in [Meijaard2007]. $$ M \ddot{q} + v C_1 \dot{q} + [g K_0 + v^2 K_2] q = T $$ where the time varying states roll and steer are collected in the vector \( q = [\phi \quad \delta]^T \) and the time varying inputs roll torque and steer torque are collected in the vector \(T = [T_\phi \quad T_\delta]^T\). I extend the equations to properly account for the lateral perturbation force, \( F \), which was the actual input we delivered during the experiments. It contributes to both the roll torque and steer torque equations. $$ M \ddot{q} + v C_1 \dot{q} + [g K_0 + v^2 K_2] q = T + H F $$ where \(H = [H_{\phi F} \quad H_{\delta F}]^T\) is a vector describing the linear contribution of the lateral force to the roll and steer equations. \(H_{\phi F}\) is approximately the distance from the ground to the force application point. \(H_{\delta F}\) is a distance that is a function of the bicycle geometry (trail, wheelbase) and the longitudinal location of the force application point. \(H_{\delta F} H = [H_{\phi F}\). I compute \(H\) for each rider/bicycle from the state space form of the linear equations of motion. $$ \dot{x} = A x + B u $$ where \( x = [\phi \quad \delta \quad \dot{\phi} \quad \dot{\delta}]^T \) and \( u = [F \quad T_\phi \quad T_\delta]^T \). The state and input matrices can be sectioned. $$ A = \begin{bmatrix} 0 & I \\ A_l & A_r \end{bmatrix} $$ $$ B = \begin{bmatrix} 0 & 0\\ B_F & B_T \end{bmatrix} $$ where \(A_l\) and \(A_r\) are the 2 x 2 submatrices corresponding to the states and their derivatives, respectively. \(B_F\) and \(B_T\) are the 2 x 1 and 2 x 2 submatrices corresponding to the lateral force and the torques, respectively. The benchmark canonical form can now be written as $$ B_T^{-1} [ \ddot{q} - A_r \dot{q} - A_l q] = T + B_T^{-1} B_F F $$ where $$ M = B_T^{-1} $$ $$ vC_1 = -B_T^{-1} A_r $$ $$ [gK_0 + v^2K_2] = -B_T^{-1} A_l $$ $$ H = B_T^{-1} B_F $$

The roll and steer angle were measured with potentiometers. The roll and steer rates were measured with a combination of rate gyros. The steer torque was measured with a torque sensor and the lateral force with a load cell. The wheel speed was measured with a DC tachometer. See my draft chapter for more details of the measurements.

All of the signals were filtered with a second order low pass Butterworth filter at 15 Hz. The roll and steer accelerations were computed by numerically differentiating the roll and steer rate signals. The mean was subtracted from all the signals except the lateral force.

I explored complementary filtering various signals but found little improvement in the signal quality. The iPython notebook worksheet details what I tried.

A simple analytic identification problem can be formulated. If we have good measurements of \(q\), their first and second derivatives, forward speed \(v\) and the inputs \(T_\delta\) \(F\), the entries in the \(M\), \(C1\), \(K0\), \(K2\) and \(H\) matrices can be identified by forming two simple regressions, one for each equation in the canonical form. I use the instantaneous speed at each time step rather than the mean over a run to improve accuracy with respect to the speed parameter. The roll and steer equation each can be put into a simple linear form $$ \Gamma \Theta = Y $$ where \( \Theta \) are the unknown parameters and \( \Gamma \) and \( \Theta \) are made up of the inputs and outputs measured during a run. \(Theta\) can generally be all or a subset of the entries in the canonical matrices. If there are \(N\) samples in a run and we desire to find \(M\) entries in the equation, then \(\Gamma\) is an \( N \times M \) matrix and \(Y\) is an \(N \times 1\) vector. The Moore-Penrose puesdo inverse can be employed to solve for \(\Theta\) analytically. The estimate of the unknown parameters is then $$ \hat{\Theta} = [\Gamma^T\Gamma]^{-1}\Gamma^T Y $$ For example if we fix the mass terms in the steer torque equation and let the rest be free the linear equation is $$ \begin{bmatrix} v(1) \dot{\phi}(1) & v(1) \dot{\delta}(1) & g \phi(1) & g \delta(1) & v(1)^2 \phi(1) & v(1)^2 \delta(1) & - F(1)\\ \vdots & \vdots & \vdots & \vdots & \vdots & \vdots & \vdots\\ v(N) \dot{\phi}(N) & v(N) \dot{\delta}(N) & g \phi(N) & g \delta(N) & v(N)^2 \phi(N) & v(N)^2 \delta(N) & - F(N)\\ \end{bmatrix} \begin{bmatrix} C_{1\delta\phi}\\ C_{1\delta\delta}\\ K_{0\delta\phi}\\ K_{0\delta\delta}\\ K_{2\delta\phi}\\ K_{2\delta\delta}\\ H_{\delta F} \end{bmatrix} = \begin{bmatrix} T_\delta(1) - M_{\delta\phi} \ddot{\phi}(1) - M_{\delta\delta} \ddot{\delta}(1)\\ \vdots\\ T_\delta(N) - M_{\delta\phi} \ddot{\phi}(N) - M_{\delta\delta} \ddot{\delta}(N) \end{bmatrix} $$ The error in the fit is $$ \hat{Y} - Y = \Gamma \hat{\Theta} - Y $$ I'm not quite sure what the "noise" model is in this model structure. It doesn't seem to be strictly an output error model, as we are not necessarily finding only the error in the forcing predictions, as \(\hat{Y}\) can be a combination of kinematic and force measurements.

This equation can be solved for each run individually, a portion of a run or if there are \(P\) runs then they can be all collected in \(\Gamma\) for best fit over multiple runs. If all the runs have the same number of time steps, \(\Gamma\) then becomes an \( NP \times M \) matrix and \(Y\) an \(NP\times 1\) vector if each run is the same length.

Secondly, all of the parameters in the canonical matrices need not be estimated. The analytical benchmark bicycle model [Meijaard2007] gives us a good idea of which entries in the matrices we may be more certain about from our physical parameters measurements. I went through the benchmark formulation and eliminated free parameters based on these rules:

- If the parameter is greatly affected by trail, leave it free.
- If the parameter is greatly affected by the front assembly moments and products of inertia, leave it free.
- If the parameter is equal or near to zero, fix it.

For the roll equation this leaves \(M_{\phi\delta}\), \(C_{1\phi\delta}\), and \(K_{0\phi\delta}\) as free parameters. And for the steer equations this leaves \(M_{\delta\phi}\), \(M_{\delta\delta}\), \(C_{1\delta\phi}\), \(C_{1\delta\delta}\), \(K_{0\delta\phi}\), \(K_{0\delta\delta}\), \(K_{2\delta\delta}\), and \(H_{\delta F}\) as free. Previous attempts at identifying all of the parameters and identification from a state space perspective confirmed that this choice of fixed parameters was reasonable for the roll equation and that little is known in the steer equation.

I start by identifying the roll equation. I have much more certainty in the roll equation estimates from first principles. I then use the assumption that \(M_{\phi\delta} = M_{\delta\phi}\) and \( K_{0\phi\delta} = K_{0\delta\phi} \) to fix these values in the steer equation to the ones identified in the roll equation, leaving less free parameters in the steer equation. This matrix symmetry is likely enforced in reality due to the simple coupling of the front and rear frames. It is also possible to solve the roll and steer equations simultaneously and enforce the symmetry but this was the easier solution for the time being. Finally, I identify the remaining steer equation coefficients.

The code for this analysis can be found in https://github.com/moorepants/BicycleSystemID/tree/master/scripts.

I have data for three riders on the same bicycle, performing two maneuvers, on two different environments. I don't suspect that the dynamics of the system should vary much with respect to different maneuvers, but there is potentially a small variation across riders and there may be variation across environments because of the differences in the wheel to floor interaction. If computing the best fit model across a series of runs this leaves these four combinations:

- All riders in both environments (n=1)
- All riders in each environment (n=2)
- Each rider in both environments (n=3)
- Each rider in each environment (n=6)

Here I'll make the assumption that the model doesn't vary much across riders or environments and give the results for the last item in the list. I run the fit over 374 runs giving about 142 minutes of data sampled at 200 Hz.

Matrix | First Principles (Whipple) |
Identified | Percent Difference |
---|---|---|---|

\(M\) | \(\begin{bmatrix} 129.86277082 & 2.29077079\\ 2.29077079 & 0.22039034 \end{bmatrix}\) | \(\begin{bmatrix} x & 2.28375768 \pm 7.05777612e-05\\ 2.28375768 & 0.20003257 \pm 1.94915567e-03 \end{bmatrix}\) | \(\begin{bmatrix} 0 & 0.30614621\\ 0.30614621 & 9.23713925 \end{bmatrix}\) |

\(C_1\) | \(\begin{bmatrix} 0. & 42.07257347\\ -0.3150094 & 1.3924634 \end{bmatrix}\) | \(\begin{bmatrix} x & 23.94008131\pm 3.15769856e-04\\ -0.88845094 \pm 4.33887933e-06 & 1.73368327 \pm 5.66893205e-07 \end{bmatrix}\) | \(\begin{bmatrix} 0 & 43.0981294\\ -182.03950055 & 24.50476423 \end{bmatrix}\) |

\(K_0\) | \(\begin{bmatrix} -114.59019659 & -2.36844326\\ -2.36844326 & -0.73938563 \end{bmatrix}\) | \(\begin{bmatrix} x & -3.91797216 \pm 1.94915567e-03\\ -3.91797216 & -0.66780731 \pm 2.30169695e-06 \end{bmatrix}\) | \(\begin{bmatrix} 0 & -65.42393996\\ -65.42393996 & -9.68078349 \end{bmatrix}\) |

\(K_2\) | \(\begin{bmatrix} 0. & 102.9447477\\ 0. & 2.19688326 \end{bmatrix}\) | \(\begin{bmatrix} x & x\\ x & 2.33973324 \pm 1.19898796e-06 \end{bmatrix}\) | \(\begin{bmatrix} 0 & 0\\ 0 & 6.50239301]] \end{bmatrix}\) |

\(H\) | \(\begin{bmatrix} 0.91545833\\ 0.01101888 \end{bmatrix}\) | \(\begin{bmatrix} x\\ 0.0086155 \pm 1.62592752e-09 \end{bmatrix}\) | \(\begin{bmatrix} 0\\ 21.81146898 \end{bmatrix}\) |

Notice that the identified model seems to have a similar eigenvalue locus as the Whipple model except for the higher weave speed and the faster caster mode. Notice the arm model has an unstable capsize mode for all speeds shown. There is a stable oscillatory mode for all speeds shown, with a similar frequency as the Whipple model for speeds above 2 m/s. In the Bode plots, the Whipple model seems to better predict the low speed behavior and the arm model better predicts the high speed behavior.

The question remains as to how well the identified model can predict the measured motion given measured inputs. This is ultimately our measurement of model quality. The following graphs give some example comparisons for various riders and various speeds of the simulation results of the model identified from all runs (all riders and both environments) along with the Whipple and Arm model.

These graphs give evidence that the identified model from all rider and both environments is better at predicting the measure motion of the bicycle given the measured inputs. The variance in the prediction is on the order of 50-80% for the identified model. I will have to run these fits on all of the runs to get an idea of the quality of the model, but this look very promising.

The following results make the assumption that the differences in the riders' inertia are negligible, but that the treadmill and pavilion floor may give different results.

*All of the following graphs follow the same color and line style scheme as the ones above. I also haven't match frequencies in the phase plots.*

The environment doesn't seem to change the predicted dynamics too much.

The following results assume that the environment has little difference on the models, but that the rider's do.

Charlie's eigenvalue plot looks very different from the other two riders, with an unstable capsize mode similar to the arm model. It is interesting that the Arm model is different for Charlie than Jason and Luke. Luke and Jason's models seem similar to each other. The frequency response of Charlie doesn't seem to vary as much with respect to the other riders.

I won't bore you with the 18 graphs, but they are all in this folder.

This method of estimating the bicycle models is the most promising that I've done so far. I am able to generate a single models for large sets of data. The resulting models act and look like bicycles, but I have enforced a lot of structure on the model by fixing a great deal of the parameters. The 4th order model still seems to be able to capture the essential dynamics and a modified steer torque equation which includes some kind of tire related torques may be able to account for the differences in the identification and the first principle models. These results give less credence to the Arm model and in the process I realized that I haven't properly linearized the Arm model in most of my previously report work. When I try to reduce my correct 19 x 19 A matrix to it's essential 4 x 4 size, I'm not properly accounting for the holonomic constraints. I hope to have that worked out so that I can compare the numerical values of the matrix entries.

The model predictions from the identified model simulation look very promising. My main question at this point, is how this model addresses the process and measurement noise and whether the parameter identification is very accurate.

]]>

For the last few weeks, I have been working with Luke to produce a steer calibration program to run on the robotic bike. Much of this time involved me getting up to speed with how to actually program the STM32 and dealing with voltage comparator issues.

The rotary encoder for tracking the steer angle has an index line which occurs once per full revolution. This is useful because we can take this incremental encoder and use it to find the steer angle at all times as opposed to only knowing angular velocity based on sequences of ticks and their timing.

The basic strategy is to put the bike on a fixture designed to hold the front fork at zero steer. We start the program, which initializes the steer tick count to zero and then waits for an interrupt from the encoder index line. While the program waits, we remove the fixture and rotate the front fork back and forth across the index line so that we can determine exactly where it is. We can then read the data obtained each time the interrupt was triggered to pinpoint the location of the index line. Assuming the front fork encoder stays fixed (i.e. the steering assembly is not taken apart), we can hard-code the number of ticks to the index line into subsequent programs so we know the steer angle at all times. An actual program might begin by initializing the steer count to zero (even though the steer angle may not be zero), then wait for the index line to trigger an interrupt. At the exact location this interrupt occurs, the steer count can be reset to the hard-coded value obtained from the calibration. After this, we know that zero steer is actually at zero.

The source code for the steer calibration program can be found on github:

https://github.com/hazelnusse/roboticbicycle/blob/steercalibration/MCP/src/steer_calibration.cc

On to the results. Two runs were performed; one for each configuration of the steer fixture. The experimental procedure was as follows:

1) Secure the steer fixture into the dropouts by first tightening the front axle nuts, then the rear axle nuts.

2) Start the program from restart to ensure TIM3->CNT == 0 while the fork is rigidly held "straight" by the fixture.

3) Loosen the front axle nuts and drop the front end of the fixture out of the front fork dropouts.

4) First turn the fork to the right, approximately 10 degrees, then back past straight ahead to about 10 degrees to the left. Repeat the procedure 9 more times.

5) Verify the encoder count and pinstate data was properly recorded in memory.

6) Issue the following command to gdb:

dump binary memoryfilenamestart_addrend_addr

where *start_addr* and *end_addr* correspond to the pinstate and ticks arrays.

7) Verify the size of the file on disk matches the size of the data in memory.

8) Write a Python script to read the data file and report the data in human-readable format.

9) Verify the Python script reads the data properly and that it matches what is displayed by gdb.

10) Flip the steer fixture upside down and repeat steps 1-9, ensuring you save the data to a different filename.

Here is a plot that shows the results of the calibration:

It is not simply a horizontal line for each run because the interrupt is triggered on the rising and falling edges of the index line. While it seems like a difference of 9 ticks between the two runs is significant, this is actually a very small fraction of a degree. It’s actually rather surprising how close the two sets are.

These radii, heights, and the number of desired lines of longitude are fed into a custom cylinder-mesh-generation function:

function [x y z] = mycylinder(r,zIn,nLong) for i=1:length(r) for j=0:nLong x(i,j+1) = r(i)*cos(2*pi*j/nLong); y(i,j+1) = r(i)*sin(2*pi*j/nLong); z(i,j+1) = zIn(i); end end

For example, here is a pin mesh composed of the 15 prescribed radii and heights and 25 lines of longitude:

Collision is deemed to have occurred if the distance between any node on 1 pin is sufficiently close to any node on another pin:

distance(i,j) = dx^2 + dy^2 + dz^2;

Here is an example of collision detection for 2 roughly-meshed pins:

Computing the post-impact velocities is rather complicated for general bodies. The dynamics in this example aren't quite right yet, but it looks believable:

]]>Hi,

I am about to submit a paper to the DSCC/MOVIC 2012 conference which is using ASME's paper system. I've read that I will need to assign copyright to ASME. I've actually already published the material under a Creative Commons license as part of my dissertation and I am the copyright holder. I will be submitting a small portion of the dissertation for this conference. I'm happy to let ASME publish the material as part of the conference proceedings as it is permissible under my CC license, but I'd like to retain the copyright to my work. I'd like to know what my options are for retaining the copyright and if there is an option to retain copyright on the form I will be required to sign?

Thanks,

Jason Moore

And this was the reply I got:

Dear Mr. Moore:

ASME requires first publication as a criterion for conference submission and publication. You will be unable to submit your paper to the DSCC conference.

Thank you,

Tamiko Fung_

This is really absurd. I'm sure people double publish stuff all of the time. How are you supposed to publish dissertations, theses and journal articles on you work *and* present it at a conference. If I present it at the conference that precludes me from publishing it in my dissertation or a journal and if if publish first I can't present it at a conference.

ASME Copyright Terms: http://www.asme.org/kb/proceedings/proceedings/copyright-terms-and-conditions

If I publish it with ASME first I'd have to get permission from them to use the material afterwards and even potentially have **to pay them a fee!:** http://www.asme.org/kb/proceedings/proceedings/post-publication-permission-to-publish

What should I do about this?

]]>

I processed all of the raw data as I've mostly described in my draft dissertation chapter. I filtered all of the signals for each run with a 15 hz low pass filter. The total number of runs from three riders that were suitable for system identification numbered 368. These runs encompassed varying duration lengths, on the treadmill and the gym floor. The maneuvers included balancing and line tracking both with and without lateral perturbations. The ideal continuous system that I'm attempting to identify for each run takes this form:

$$ \dot{x} = \begin{bmatrix} \dot{\phi} \\ \dot{\delta} \\ \ddot{\phi} \\ \ddot{\delta} \end{bmatrix} = \mathbf{A}x + \mathbf{B}u = \begin{bmatrix} 0 & 0 & a_{\dot{\phi}\phi} & 0\\ 0 & 0 & 0 & a_{\dot{\delta}\delta}\\ a_{\ddot{\phi}\phi} & a_{\ddot{\phi}\delta} & a_{\ddot{\phi}\dot{\phi}} & a_{\ddot{\phi}\dot{\delta}}\\ a_{\ddot{\delta}\phi} & a_{\ddot{\delta}\delta} & a_{\ddot{\delta}\dot{\phi}} & a_{\ddot{\delta}\dot{\delta}} \end{bmatrix} \begin{bmatrix} \phi \\ \delta \\ \dot{\phi} \\ \dot{\delta} \end{bmatrix} + \begin{bmatrix} 0 & 0 \\ 0 & 0\\ b_{\ddot{\phi}T_\delta} & b_{\ddot{\phi}F_{c_l}}\\ b_{\ddot{\delta}T_\delta} & b_{\ddot{\delta}F_{c_l}} \end{bmatrix} \begin{bmatrix} T_\delta\\ F_{c_l} \end{bmatrix} $$ $$ y(t)= \begin{bmatrix} \phi \\ \delta \\ \dot{\phi} \\ \ddot{\delta} \end{bmatrix} = \mathbf{C}x = \begin{bmatrix} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{bmatrix} \begin{bmatrix} \phi \\ \delta \\ \dot{\phi} \\ \ddot{\delta} \end{bmatrix} $$During the identification, the lateral perturbation force \(F_{c_l}\) is set to zero for all the runs with no perturbations. The goal of the identification is to find the non-zero entries of the \(\mathbf{A}\) and \(\mathbf{B}\) matrices. I've been trying out several solutions to the system identification and have had varying results:

- I'm able to get the best fits by assuming that their is no process noise. This degrades the estimation of the entries because they are now chosen such that they fit the noise component in the model.
- I've tried combinations of identifying the initial state, the Kalman gain for the process noise, fixing the kinematical equations to 1, weighting and trying different options with the pem function in Matlab from Focus to SearchMethod. I generally get worse fits the more parameters I introduce . I don't believe that the algorithm is actually finding the global mimina for each run due to the fact that I get better fits with the minimum set of free parameters.
- I'm not sure why this problem doesn't have an analytical solution as it is simple least squares problem. I'm going to write it out myself to see if I can get to the bottom of it.

There are some issues that I haven't completely worked out with the system identification for each run, but I still get reasonably "good" results when looking at the results holistically with respect to all of the runs.

As I've shown in earlier blog posts, some coefficients are tightly clustered and there is some spread in others with the roll Whipple roll acceleration equation better describing the roll equation than the steer equation.

I imported this data into R to try out some basic regression fits on the coefficients. I started with the the assumption that the coefficients changed with respect to speed in the same fashion as the Whipple model (either constant, linear or quadratic). I then fit a basic regression model and a basic mixed effects model with the repeated experiments with respect to speed as groups so that the fits wouldn't be as biased to the speeds at which I had more data.

The fits for the two models are similar for each coefficient. The \(a_{\ddot{\phi}\dot{\delta}}\) and the \(a_{\ddot{\delta}\dot{\phi}}\) have slopes in the opposite direction as compared to the Whipple model in the previous plot (I'm working to combine these plots for clarity but using Python, Matlab, and R simultaneously in my software is a little troublesome...), but other that that the fits seem believable. I've yet to check through the numerical statistics such as T tests, P values and model comparison. I feel like the spread in \(a_{\ddot{\phi}\phi}\) seems to be large for every speed and I'm not sure how well that is being predicted.

We can also look at the data from the Bode plot point of view and this turns out to show greater agreement between the first principles model and the empirical model.

The Bode plot shows that the magnitude and phase are qualitatively similar with some offset in each. We are primarily interested in the decade bounded by 1 and 10 rad/s for our 4th order model. I would suspect that the magnitude of the Whipple model would be larger than the magnitude of the empirical model because I know that the steer torque we measured is more than the what the Whipple model predicts for a given steer and roll trajectory. This gain offset is even greater at 5 m/s:

I'm having trouble getting the phase plots to work every time due to the fact that the phases for multiple models don't always match. They can be multiples of 360 degrees off from each other. Getting this phase matching programed correctly has been a headache for some reason. I'll figure it out eventually I guess.

The eigenvalues of the identified A matrix can be computed for each run and compared to the Whipple model.

There is a great deal of spread, but the blue dots give the frequency of the oscillatory eigenvalues. At 2m/s the Whipple model seems to match. The mean frequency is a bit higher at higher speeds, but the trend is there. The black dots are real parts of the eigenvalues. The unstable dots are closer to the real axis than the Whipple model but decrease and there is some indication of predicting the weave critical speed. There is a lot of spread in the real eigenvalues around the capsize mode but is increasing with speed.

The data in which the noise was not estimated actually looks a little clearer (but not necessarily correct).

This view shows more agreement with the Whipple model. The weave critical speed is lower, there is spread in the capsize but it is there, and the imaginary part of the modes are well predicted. I'm going to work on these plots to improve their clarity. I've hand drawn lines of what I think the fit may be for the weave and capsize modes.

Now we can also make an eigenvalue plot of the empirically derived model which was found form regressing the coefficients and using the mixed effects model.

I'm not sure what to make of these two models yet. They both give two oscillatory modes for much of the speed range that have very different frequencies and I'm not sure how well they would fit the data which I showed on the previous plots. I'm going to try to have all these plots together, but I have to figure out RPy a little so I can merge the data into the BicycleID program.

- There is a great deal of spread in the data, but trends are there and connection to the first principles models.
- The system id is not as repeatable as I'd hoped. I think some better preparation for the data is needed along with figuring out how to proper fit the process noise model.
- The Bode plot view is very nice and the standard deviation is low. It seems that in general models with varying parameters can give matching frequency response. This may implies that there may not be a unique set of parameters. Putting bounds on the search may force them to be more where I want them, but I'm not sure if that would be a good or bad idea.
- The spread in the root loci is larger for the models in which noise was accounted for, but smaller when not. The latter shows some agreement with the Whipple model.
- The empirically derived model based on fitting the coefficient curves is different than the Whipple model. I'm going to try to feed forward simulate it and see if it actually predicts the outputs reasonably.
- Lastly, I'm going to work with the analytical linear Whipple model equations to try to determine which parameters are most likely incorrect and where there is room for some new parameters.