Simulation of
a free-rolling bicycle
This example is a simulation done with DynaMo, our C++ class library for motion dynamics simulation, embedded in our GDP animation system. It shows how the stabilty of the motion of a bicycle depends on the geometry of the bicycle.
Background
The bicycle is constructed by connecting its parts (two wheels, a fore fork, a frame and the crank) using standard connections (pin-joints and an orientation constraint between the crank and the rear wheel). These connections impose constraints on the relative motions of the parts, which the dynamics subsystem imposes by calculating and applying the reaction forces that hold the parts together. The interaction between the wheels and the surface that the bicycle is rolling on is also modelled using such a constraint (a constraint that makes sure that the wheel stays on the surface, and that it does not slip). More on the theory behind the constraint satisfaction problem is described in the articles that can be found here.
The example shows rather complex motion behaviour can be described using few and simple building blocks.
In the animations presented below, the bicycle is set in motion by exerting a torque on the crank. The orientation constraint between the pedals and the rear wheel transfers part of this torque to the rear wheel, and -because the rear wheel cannot slip over the surface- the rear wheel starts rolling. The connections between the rear wheel, the frame, the pedals, the fore fork, and the front wheel transfer this forward motion to the other parts of the bicycle.
When the bicycle is up to speed it is given a sideways push. The way the bicycle continues moving differs between the bicycles in the animations below. The differences are caused by the different shapes of the fore forks of the subsequent bicycles, and by the angle at which the steering column is mounted to the frame. Both these factors (along with the radius of the wheel of the bicycle) determine the so-called trail of the bicycle: the distance between the point where the front wheel touches the ground, and the intersection point of the steering axis and the ground). As long as the wheel is trailing the steering axis intersection point, the bicycle will have a stable behavior. If it is leading, the front wheel will have the tendency to flip over to make for a positive trail. This is described in more detail here.
An unstable bicycle
The fore fork of our first bicycle is bent and then extended forward a long way, to cause the wheel to lead the intersection point of the steering axis with the floor. The behaviour of this bicycle is unstable: even without being pushed over, the bicycle is starting to steer, and when the bicycle is shoved sideways, it simply falls over, without the front wheel turning in a way that would change the falling motion into a turn.
| View the movie of this simulation: |
|
 |
|
A stable bicycle
Our second bicycle has a straight fore fork which is reasonably slanted (much like that of a motor cycle). This causes the front wheel to trail the intersection point of the steering axis with the floor, which causes a stabilising effect on the motion of the bicycle. As it is pushed over, the front wheel turns in such a way that the bicycle starts a turn in the direction it was pushed, thereby using the sideways pull by gravity as a centripidal force. So this is a stabilising effect, which would make the bicycle much easier to steer. Unfortunately, as there is no driver further controlling the motion of the bicycle, the stabilising effect is not enough to keep the bicycle completely balanced, and the bicycle falls over.
| View the movie of this simulation: |
|
|
|
A stable and balanced bicycle
| View the movie of this simulation: |
|
|
|
Since the simulation calculates the forces at work in the bicycle, these are easily visualised. The animation below shows the same simulation as above, with the addition of the reaction forces.
| View the movie of this simulation: |
|
|
|
Performance
DynaMo provides for simulations that are calculated as one watches. The animations presented above are calculated and displayed at about 25 frames/sec (on an SGI Indy R5000, and a Sun SPARCstation 5). This opens up the possibility of interactive simulations.
Author
Bart Barenbrug
Dept. of Mathematics and Computing Science
