slipstream-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Slipstream-devel] Rider upper body roll and translation


From: Dimitris Papavasiliou
Subject: Re: [Slipstream-devel] Rider upper body roll and translation
Date: Thu, 22 Dec 2011 17:33:07 +0200

Hey,

> Thanks for the interesting read. I'm quite surprised those solutions
> helped the wheelie situation; perhaps the gyroscopics of the wheel are
> enough to keep in facing relatively forwards.

The results aren't dramatic but it does allow you to wheelie when
you're more or less upright with little shake on the way down.  If you
wheelie at a 20 deg. lean things still get ugly.  Besides the
gyroscopics another relevant fact to keep in mindo would be that
there's a lot of damping in the steering head, both due to the
steering damper as well as the the rider's upper body.  So in the
absence of an input torque it's reasonable that the steering head
angle wouldn't change much due to gravity alone, especially at low to
zero lean angles.

> I am generally opposed to solutions like a shift throttle cut, simply
> because these are direct rider assists in order to get around
> limitations of the controller. Cutting the throttle while shifting with
> a controller such as a wheel, set of bars etc should be quite intuitive.
> Then again, modern racing motorcycles do already have in-built
> 'quick-shift' systems which cut the throttle for you. In terms of SBK or
> MotoGP cutting the throttle is a thing of the past.

I'm generally opposed to riders being assisted by electronics in a
race setting (well in the real world it's a matter of controls too,
usually that you don't have enough arms or fingers, or that even if
you did you wouldn't be able to coordinate them and move them fast
enough).  The whole point is to test the ability and finesse of the
rider quite unlike the road where safety's first.  But there's another
point besides the fact that you upset the chassis with a shift (which
happens in the real world as well anyway).  The problem is that
normally you can't shift gears under full throttle.  When the gearbox
transmits power the dog collar is not free to slide out of the gear
due to friction so you _have_ to cut power to switch gear.  Power loss
occurs also due to the fact that for some short time interval the
collar is in transit from one gear to the next and not engaged to any
of the two.  Quickshifters simply allow you to minimize the time
power's cut off by cutting the spark for you when needed and for as
little time as possible.  So the current transmission in Slipstream is
cheating compared to the real world since no power-cut occurs.  I'd
like to address this somehow but am not sure how short of simulating
the dog collars sliding in and out of the gears inside the
transmission.  Though possible this would be overkill in terms of
computation cost to realism gain.  Perhaps a threshold on the torque
transmitted by the gearbox can be set above which no shifts are
possible together with a shifting interval during which the
transmission is in effect in neutral.  This would then force you to
close the throttle yourself in order to shift and possibly help with
the spike too as some of the energy stored in the crankshaft would be
lost during the neutral interval.  Figuring out what to set this
torque and interval to would be an interesting problem though...

> I think solution A is heading in the right direction for the rider
> model; When a rider is on a bike that is accelerating, they have most of
> their weight on their rear/legs and little on their arms. If the rider
> is to apply a steering torque, it is almost entirely relying on how much
> effort they put into the bars with their arms. When a rider is in a
> braking situation, the majority of their body weight is on their arms,
> so the act of putting their weight onto one arm rather than the other
> produces a much greater steering torque. Most riders do this without
> realising. You've partly picked this up with your solution A, but you
> should also incorporate the reverse into your rider model. It's really
> quite obvious how much harder it is to turn in while braking in
> slipstream than in real life.

Assuming by solution A you mean the control system that reduces input
torque as the load on the front wheel diminishes, then I think you got
it wrong.  What you describe does in fact happen and load transfer to
the front during braking does indeed allow one to provide less
steering torque through muscles but it can also easily lead to
unwanted steering input, loss of input precision etc.  I'm not sure
these effects can be simulated.  There is currently a link between the
upper body of the rider and the steering head but it is not very
accurate.  By that I mean that the upper body, including arms, hands
etc is considered as one body so in order to account for the fact that
in the real world the rider is connected to the steering through the
hands the joint between lower and upper body is modified accordingly
in terms of stiffness and damping.

In other words: in the real world a tank-slapper developed at the head
would feed forces to the rider's body through the arms and therefore
shake it around.  The body in turn would feed back into the head
providing some damping.  If the rider's body was directly tied to the
steering head the interaction would be different so the model changes
the stiffness and damping of the waist joint in order to compensate
and get the correct interaction.  That's why the yawing motions of the
upper body are so exaggerated when replaying.

The waist joint has no pitch freedom through, which means the upper
body can't react to load transfer by diving or standing up so the
steering head is isolated from such feedback.  It would be easy to
allow diving but then we'd need some way of making sure the
interaction developed between body and steering is correct and some
way to estimate the correct pitch stiffness and damping at the joint.
 The parameters for yawing were based on published experimental data.
I haven't seen any models with pitching freedom for the rider body.
Perhaps experimentation can yield interesting results.  At the very
least it'd be useful when animating the rider.

Anyway the proposed control system, which is currently in the CVS,
doesn't have any of this in mind.  What it does is drop of the
steering torque as the load on the front becomes too low.  The idea is
that you don't want to steer when there's no load as bad things will
happen so when you sense that steering doesn't do much any more you
stop applying torque until you've got traction again.  The real rider
does this automatically by making sure that the steering head points
more or less where it should but in the simulation this can be
unrealistically difficult so some sort of automatic system should be
considered a valid aid and not cheating.

> I don't have anything really against solution B. You do see in racing
> that when changing sides under acceleration, the real bikes do often
> slam to lock as the riders try to force them over. I haven't experienced
> how exaggerated this head-shake is, but it seems plausible and realistic
> that a head-shake should be there.

You can experience it easily I think by changing the rider
stiffness/damping values to the ones proposed in the initial mail
although as explained in the follow-up I now use a yaw stiffness of 70
Nm/rad which is more reasonable I think.  This would allow you to test
the effectiveness (or lack thereof) of the stabilization control
systems.

Let me know if I misunderstood what you were referring to by solution A and B.

Cheers,
Dimitris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]