Personal tools

Blogroll

Press via Catherine Hess

By Jason Moore from Blog. Published on Nov 21, 2012.

Catherine Hess, Ron Hess's daughter, competed in a Welcome Trust science writing competition and got honorable mention. More recently the essay has been published in the Guardian and has been spreading around the web.

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/

David Levinson on The Explorer I Anomaly

By Jason Moore from Blog. Published on Nov 21, 2012.

David Levinson who wrote two nice books with Thomas Kane, of which I've spent a great deal of time reading over the years spoke this week at UCD. Check out the talk:

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.

To walk or to run

By Jason Moore from Blog. Published on Nov 14, 2012.

My talk from DSCC 2012

By Jason Moore from Blog. Published on Nov 07, 2012.

  • Introduction: Name, place, project, website
  • Open Loop Plant model validity, Whipple deficient, motorcycle more data, tires, rider, more data
  • statistical significance, ashamed even of me
  • the human controller, most complex, link to handling, controls is too narrow, we need collaboration with other fields
  • embrace open science for reproducible, reusable, rapid research
  • data: make single track problem into big data problem, public repos, data papers, will allow us to rapidly generate models and validate models
  • environing validating against hundreds of data sets
  • data is cheap
  • software, if we open data, same goes for software, code should be just as open as the equations in our papers, we need to know if gives correct results and we need the ability to hack it,
  • meta software project that contains code for working with data, computing standard functions, models, controllers
  • references, still manageable
  • reproducibility: can we actually reproduce old experiments with modern methods?
  • Meta papers, more review papers to put the previous research findings into perspective

Future of Bicycle/Motorcycle Dynamics

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.

Vehicle Model Validation and Creation

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.

Statistical Significance

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.

Understanding the Human

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.

Open Science

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.

Data

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.

Software

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.

References

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.

Reproducibility

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.

Meta Papers

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.

Google Summer of Code, Mentor Summit 2012

By gilbertgede from Gilbert Gede's Blog. Published on Oct 29, 2012.

I probably should have written a blog post during the summer, displaying Angadh’s work . . . oh well. SymPy sent me as one of 3 mentors to the GSoC Mentor Summit this year, at the Googleplex. I was very excited to go, meet some of the other SymPy developers (Matthew and Stefan), and meet […]

Single Track Vehicle Dynamics at DSCC 2012: A Recap

By Jason Moore from Blog. Published on Oct 22, 2012.

We were fortunately able to get two sessions accepted to this years Dynamic Systems and Control Conference focused around the topic of single track vehicle (mostly bicycle and motorcycle) dynamics, control, and handling. Researchers from around the world participated. It was great to see many of the faces from the 2010 BMD Conference and many other new faces.

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:

Tires

  • 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

Human

  • 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?

Community

  • 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
and "cool" names:
  • RIDE
  • ROLL
and not so good names:
  • 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!! :)

Shiny 3D Butt

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

 

Dissertation Recap

By Jason Moore from Blog. Published on Aug 28, 2012.

I've finally finished my dissertation. I turned in the the official version on August 21st. My school has a tradition of ringing a bell and announcing that you are now a doctor, which is followed by the office employees clapping in the Grad Studies office when someone completes their PhD. My roommates and friends were talking about how small the bell was and how the graduate didn't even get to ring it at dinner the night before I had to do this. It is actually pretty anti-climactic for years of toil. It would feel great to whack a giant gong after finishing. So the conversation at dinner started to transform into my friends coming along with me carrying an assortment of instruments, bells, and noise makers. I wasn't sure any of them would actually show up the next morning but at 10 am sharp folks started appearing at my house. Robbie had his oboe, Amanda had bicycle bells, and David with some Tibetan chimes. We bicycled over to Mrak hall to find Lauren and Kentaro waiting for us. I went in and met with Amelia who also happened to be the first person I'd interacted when checking out Davis. She was our department's grad student coordinator my first couple years here. She checked over the forms and gave me a piece of paper saying I was a doctor and we proceeded to the main desk to "ring the bell". She rang the bell, announced me, and folks started clapping as I pulled the Butterpat conch shell from my bag and gave it a mighty blow. Folks popped their heads out of their office doors as the rest of the crew bounded in the main door playing all of the instruments. I think the office appreciated it and I was super happy to having all my friends there giving me support this last day (they've put up with my anti-social dissertation finishing behavior for quite a while now).

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).

Bowling thesis is available to lab members

By Andrew Kickertz from Blog. Published on May 31, 2012.

In case you want to know more of the gory details about the bowling project, there is a link to the current version of my thesis at the top of the project page.  You have to be logged in to view it, and I request that you not redistribute copies of it all over the internet.

 

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

Science of Riding a Bicycle Video

By Jason Moore from Blog. Published on May 15, 2012.

Gabriela Quirós at KQED Quest interviewed me about our research on bicycle dynamics and also David Takemoto-Werts at the US Bicycling Hall of Fame for this piece about the "Science of Riding a Bicycle". It turned out pretty cool and I'm happy to have helped with it. The link to the website is here: http://science.kqed.org/quest/video/the-science-of-riding-a-bicycle/.

Posted my exit seminar video

By Jason Moore from Blog. Published on May 11, 2012.

 

 

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).

Bowling collision simulation using Blender

By Andrew Kickertz from Blog. Published on Apr 30, 2012.

For the past few months I have been developing a Matlab-based bowling-oriented physics engine for simulating the collisions of balls and pins, as well as the lane, gutters, and side walls.  This 'from-scratch' approach has provided much insight into collision detection and collision response, and has had some fruits.  Simulating 2-dimensional collisions (imagine an overhead view of a bowling lane) with or without friction accounts for many of the phenomena observed in bowling.  In particular, how pinball varies with the final lateral position and final heading of the ball is captured fairly well by a 2D model.


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:

 

 

Identification of the benchmark canonical form

By Jason Moore from Blog. Published on Apr 01, 2012.

Model structure

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 $$

Data processing

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.

Identification

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.

Results

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)
for a total of 12 combinations.

All riders in both environments

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}\)
Charlie-Jason-Luke-HorseTreadmill-PavillionFloor-eig.png
This plot shows the root locus of the real (solid line) and imaginary (dotted line) parts of the eigenvalues for three bicycle systems: Identified (black), Whipple (blue), and the Whipple + Arms (model). The first principles models are calculated by taking the mean of the linear model with respect to the three riders. The identified model was computed with all of the available run data and is the "best fit" model for all of the data for all riders and both environments.
Charlie-Jason-Luke-HorseTreadmill-PavillionFloor-Tphi.png
The frequency response for the roll torque to roll angle transfer function for three models: identified (black), Whipple (blue), and Arm (red) for four speeds: 2.0 m/s (solid), 3.0 (dashed), 5.8 (dash-dot), 9.0 (dotted).<br /> <br /> First Principles: Mean of all riders.<br /> Identified: All riders, both environments.<br />
Charlie-Jason-Luke-HorseTreadmill-PavillionFloor-Tdel.png
The frequency response for the steer torque to roll angle transfer function for three models: identified (black), Whipple (blue), and Arm (red) for four speeds: 2.0 m/s (solid), 3.0 (dashed), 5.8 (dash-dot), 9.0 (dotted). First Principles: Mean of all riders. Identified: All riders, both environments.

 

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.

Example fit at 2 m/s
Time histories of the roll and steer states showing example fits against the measured data (green) compared to the three models: identification from all runs and both environments (I), Whipple model (I) and the Arm model (A).
Example fit at 4.25 m/s
Example fit at 4.7 m/s

 

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.

All riders in each environment

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.

Horse Treadmill

Charlie-Jason-Luke-HorseTreadmill-eig.png
Charlie-Jason-Luke-HorseTreadmill-Tphi.png
Charlie-Jason-Luke-HorseTreadmill-Tdel.png

Pavilion Floor

Charlie-Jason-Luke-PavillionFloor-eig.png
Charlie-Jason-Luke-PavillionFloor-Tphi.png
Charlie-Jason-Luke-PavillionFloor-Tdel.png

 

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

Each Rider on Both Floors

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

Charlie

Charlie-HorseTreadmill-PavillionFloor-eig.png
Charlie-HorseTreadmill-PavillionFloor-Tphi.png
Charlie-HorseTreadmill-PavillionFloor-Tdel.png

Jason

Jason-HorseTreadmill-PavillionFloor-eig.png
Jason-HorseTreadmill-PavillionFloor-Tphi.png
Jason-HorseTreadmill-PavillionFloor-Tdel.png

Luke

Luke-HorseTreadmill-PavillionFloor-eig.png
Luke-HorseTreadmill-PavillionFloor-Tphi.png
Luke-HorseTreadmill-PavillionFloor-Tdel.png

 

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.

Each rider in each environment

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

Discussion

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.

 

Robotic bike steer calibration

By Kenneth Lyons from Blog. Published on Mar 08, 2012.

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 memory filename start_addr end_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:

Steer Calibration Tick Plot
A graphical depiction of the data obtained from the steer calibration experiment.

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.

Pin-pin collision detection and response

By Andrew Kickertz from Blog. Published on Mar 07, 2012.

Over the past couple weeks I've been developing a method to detect collisions between pins, modeling them as meshes.  I'm also thinking about describing the pins as parametric surfaces, but that's another can of worms.  The radius of the pin is defined at 15 heights as specified by the USBC:

Bowling pin dimensions
As specified in the USBC 2010 Equipment specifications and certification manual

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:

15-30 pin mesh
Rainbow colored pin mesh with 15 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:

I need help with conference copyright issues

By Jason Moore from Blog. Published on Mar 07, 2012.

I'm wrapping up my dissertation (moorepants.github.com/dissertation) and want to present some of the material in it at some upcoming conferences in my field. One that I am hoping to go to is: http://mne.psu.edu/dscc2012/, which is an ASME conference. ASME requires you to sign over copyright when you submit a paper for the conference. I sent them this email inquiring about options to retain my copyright:

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?

 

Improved results on the bicycle identification

By Jason Moore from Blog. Published on Mar 05, 2012.

I'm about to start writing up the results I've obtained on identifying a linear bicycle model. As I've explored the data, my confidence growing in it but there are still some issues. This is the current state of affairs.

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.

Equations of Motion Coefficient Estimation

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.

Equations of Motion Coefficients
This plot shows the data for the estimate of the equation of motion coefficients (bottom two rows and neglecting the lateral force coefficients) for 251 runs. The process noise and initial state were estimated and the kinematical differential equations had one free parameter. These runs had a mean fit percent greater than zero. The lines represent the coefficients as predicted by the linear Whipple model for these riders and bicycle.

 

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.

Coefficient Regression
This plot shows the regression results for the basic regression (black line) and mixed effects model (red line) for the runs with a 50% or greater mean fit percentage (i.e. the higher quality fits).

 

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.

Bode Plots

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.

Empirical Bode Plot 2 m/s
This shows the steer torque to roll angle (left) and steer torque to steer angle (right) transfer functions. The red line is the linear Whipple model and the blue line is the mean of the identified models with the blue line bounding the standard deviation.

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:

Empirical Bode Plot 5 m/s
The empirically derived model is the blue line with bounding blue dotted lines showing the standard deviation. The red line represents the Whipple model.

 

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.

Root Loci

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

Empirical Root Loci (Noise Estimated)
The real and imaginary parts of the eigenvalues for each run as a function of speed. The solid lines are the Whipple model predictions. This is from data in which the initial state, and noise were identified.

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).

Empirical Root Loci (No Noise Estimation)
The blue dots give the oscillatory mode frequency. The red dots are the real parts of the oscillatory modes. The dark dots are the purely real eigenvalues. I've traced some lines over these to try to visualize the modes that may be predicted.

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.

Emprical Model Root Loci
This shows the root loci of the empirically derived model from regressing the A and B coefficient data.
Emprical Model Root Loci Mixed Effects
This is the root loci of the empirical model derived from the mixed effects regression.

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.

Conclusions

  • 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.

GSoC, Week 12

By gilbertgede from Gilbert Gede's Blog. Published on Aug 13, 2011.

Well, this past week was the final “full” week of the 2011 Google Summer of Code. The ‘soft’ pencils down date is Monday. This week, I mostly rewrote interfaces to some functions and classes. I should probably go back through previous blog posts and update those to show how they are different, so if anyone […]

GSoC, Week 11

By gilbertgede from Gilbert Gede's Blog. Published on Aug 06, 2011.

Well, it looks like there is a little over 1 full week left. This week’s post probably won’t be too long. I have a list of the last few things left to work on. The last few (big) pieces are: finishing code output, making sure you can bring non-contributing forces into evidence, and documentation work. Finishing […]

GSoC, Week 10

By gilbertgede from Gilbert Gede's Blog. Published on Jul 29, 2011.

Week 10….? This week, there really isn’t that much to report. Week 10 was supposed to be finishing up the pretty and LaTeX printer, and I have done most of that. Tests and documentation need to be written for both though; I think I’ve learned that things haven’t really been coded successfully until you’ve done […]

GSoC, Week 9

By gilbertgede from Gilbert Gede's Blog. Published on Jul 23, 2011.

Week 9 already….? Also, my internet connection is down, so this post is a little later than I planned…. So there was some progress this week. A lot of it was in doing the math for the linearization process. Linearization is normally easy, but when dealing with dependent quantities becomes more complicated. It requires treating […]

GSoC, Week 8

By gilbertgede from Gilbert Gede's Blog. Published on Jul 16, 2011.

I don’t have as much to talk about this week, as I spent two days in travel. Mostly, I worked on the sphinx documentation for mechanics. I am continuing with the previous organization of the documentation: first the mathematical descriptions, then the SymPy implementations. I’m still not convinced that this is the best way to […]

GSoC, Week 7

By gilbertgede from Gilbert Gede's Blog. Published on Jul 09, 2011.

I submitted my pull request a little while ago for my code. Currently, it looks like I’m waiting on a few things. I think the biggest thing is the pull request Brian Granger has opened. I’ve already written a branch which uses his code, and everything works. I just have to wait for his pull […]

GSoC, Week 6

By gilbertgede from Gilbert Gede's Blog. Published on Jul 02, 2011.

During week 5, I submitted my pull request. During this past week, I have been working on getting that code to high enough quality to be accepted. It looks like Brian Granger has implemented a change in SymPy’s derivatives in a branch which allows for differentiation of arbitrary things; this includes functions and derivatives, allowing […]

GSoC, Week 5

By gilbertgede from Gilbert Gede's Blog. Published on Jun 25, 2011.

At the end of last week, a lot of the functionality I was aiming for was completed.  I think the code can now compute equations of motion.  I’m still working on some more advanced tests, but for simple cases I know it works. I submitted a pull request for pulling my work into sympy:master.  It […]

GSoC, Week 4

By gilbertgede from Gilbert Gede's Blog. Published on Jun 18, 2011.

Things went pretty well this week.  Last weekend, I implemented a Dyad class.  We decided to do this for a number of reasons; but largely it was to allow the end-user the freedom to express a body’s rotational inertia as sums of components in different frames.  More information about dyads can be found here: http://en.wikipedia.org/wiki/Dyadics, or […]

ATLAS and GSL

By Dale Lukas Peterson from Blog. Published on Nov 19, 2009.

ATLAS (Automatically Tuned Linear Algebra Software) is a Fortran/C library that provides BLAS (Basic Linear Algebra Subprograms) 1,2, and 3 level support and some routines from LAPACK.  BLAS level 1,2, and 3 are nothing more than routines for vector - vector, matrix - vector, and matrix - vector operations, respectively.  All of Matlab's matrix functionality is based on ATLAS and LAPACK.  They are thoroughly tested, have a large user community, and are open source using BSD style licenses.

GSL is the GNU Scientific Library.  It provides a ton of functionality, and it makes use of ATLAS if you have it installed on your machine.  My main interest was in being able to use it to do numerical integration of differential equations and for solving systems on nonlinear equations.  I want something that is well tested and runs at compiled speeds, and is open source.  For Python, SciPy offers some of this, but the numerical integrator is more limited than the GSL numerical integrator.  GSL is licensed under GPLv3.

Here is what I did in order to download, compile, and install ATLAS, LAPACK, and GSL, all from source.  I used ATLAS 3.9.17, LAPACK 3.2.1, and GSL 1.13.  These were the most recent versions as of November 23rd, 2009.  I am running Kubuntu 9.10, on a 64-bit machine (Core 2 duo).

I configured each library to install to the usr folder in my home folder so that my system libraries would be unaffected (this is the --prefix=$HOME/usr in all the configure commands).  Additionally, to date I haven't been able to get the most recent version of ATLAS to build all the shared libraries successfully (some build, some don't, I'm awaiting responses from the developers), but the static libraries build just fine on my machine.

  • As root, disable CPU Throttling (either su before these commands or prefix them by 'sudo '):
cpufreq-set -c 0 -g performance
cpufreq-set -c 1 -g performance
  • In your terminal, go to your home folder, and create a folder called usr in your home folder (if it already exists, skip to the next step):
cd
mkdir usr
  • Go to a temporary folder and download the tarballs:
cd /tmp
wget http://downloads.sourceforge.net/project/math-atlas/Developer%20%28unstable%29/3.9.17/atlas3.9.17.tar.bz2?use_mirror=softlayer
wget http://www.netlib.org/lapack/lapack.tgz
wget ftp://ftp.gnu.org/gnu/gsl/gsl-1.13.tar.gz
  • Untar the tarballs (creates an ATLAS folder and a gsl-1.13 folder with the contents of the tarball in it):
tar xvf atlas3.9.17.tar.bz2
tar xvf gsl-1.13.tar
  • Note that there is an install pdf (ATLAS/doc/atlas_install.pdf) that is worth reading if you want to understand how ATLAS works.
  • cd to the ATLAS folder, create a build directory, and run the configure scrip.  The following was what I did for my laptop, which is a 64-bit machine (-b 64), running at 2.0GhZ (-DPentiumCPS=2000), and install them in the usr folder in my home directory (--prefix=$HOME/usr), and link them against the netlib lapack file (--with-netlib-lapack-tarfile=../../lapack.tgz).  You should change 64 to 32 if you are running a 32 bit machine, and 2000 to the appropriate speed (or leave that part out altogether):
cd ATLAS
mkdir build
cd build
../configure -b 64 -D -c -DPentiumCPS=2000 --prefix=$HOME/usr --with-netlib-lapack-tarfile=/tmp/lapack.tgz
  • Now run make to compile and link everything (the first step takes about 10-15 minutes on my machine), and run the checks and timings:
make
make check
make ptcheck
make time
  •  Install the ATLAS include files and library files:
make install
  • Almost done.  Configure, build, and install GSL:
cd /tmp/gsl-1.13
./configure --prefix=$HOME/usr
make
make install
  • Now, add the include directories and library directories to your C_INCLUDE_PATH and LIBRARY_PATH environment variables.   You can do this by adding the following to your .bashrc:
export C_INCLUDE_PATH=$C_INCLUDE_PATH:$HOME/usr/include
export LIBRARY_PATH=$LIBRARY_PATH:$HOME/usr/lib

Finally, test everything out.  Here is a .c file for the Van der Pol oscillator, along with a make file.  Put the two files in the same folder, type make at the terminal, and if all went well, it will compile to vanderpol.out, which  you can then run to integrate the equations of motion.

vanderpol.c

Makefile

Document Actions