Vehicle Simulation

Page created: 2007. Last updated: June 2020

This web page is for people using Juice specifically for the purpose of wheeled vehicle simulation. The main purpose is to provide help with things that are not obvious from the existing Juice documentation.

Juice can be used for many things, and there are lots of examples to study, but not many examples of wheeled vehicles. In particular, the information here is for simulations that are supposed to be valid approximations of real vehicles, and not just toys. Therefore, questions about the validity, or "truth" of the results, and their reliabilty or consistency, will also be dealt with.

Click for the official Juice website

There is some basic documentation online at the above site, including a good introduction to the user interface.

Note added in June 2020:The link above no longer works because that web domain no longer exists. It seems the software is no longer supported. The neccessary files (including the missing .dll files) are available on this website using the link below.

Click to download .zip archive

Official technical documentation is very sparse. Some attempt is made here to correct that shortcoming, but there are many things about Juice that remain somewhat mysterious. The author of this page does not fully understand everything, and some explanations may be incorrect! The reader is asked please to help by pointing out faults, and making suggestions for improvement. Sections where uncertainty exists are presented in italics.

Table of Contents

  1. Getting Started with Juice
    1. Requirements (Hardware and Software)
    2. General comments
      Simulation
      • Design
      • Action
      • Multiple phases
    3. Examples
      • A Pendulum
      • Non-tilting Trike
  2. Model design
    1. Beams
      • BOX
      • CYLINDER
      • BALL
    2. Joints
  3. Dynamics
    1. Gravity
    2. Motors
      • Slider motors and hinge motors
      • Motor control
      • Sources of motion
      • Juice main engine
    3. Behavior
      Network Behavior
    4. Other design aspects of dynamics
      • Mass
      • Gain and Max force
  4. Basic Models
    1. Simple model control
      • Non-tilting trike
      • Gyroscope effects
    2. Advanced steering control
      • Free-tilting trike
      • Bike
  5. Advanced Network behaviour
    1. Roll, pitch and yaw feedback
    2. Combining inputs
  6. Measures and Dimensions
  7. Simulation Parameters
  8. Validity and Calibration
  9. More Examples
  10. Unanswered questions
  11. Contact information

Getting Started with Juice

Requirements

  1. Obviously, you must first install Juice. It appears that many times the installation fails because there are two files missing, called msvcp70.dll and msvcr70.dll. These are legacy files from Win98, they will not be updated in later versions of Windows. They were not in the original Juice setup program because they were part of Win98 at the time. If you can't find them anywhere, click below:

    Save them into the same folder where you have juice.exe, or put them in the \Windows\System32 folder.

  2. Juice does not need much computer power. You can run it without any special hardware.

  3. A good joystick is not essential, you can get by using the keyboard (up-down, and left-right arrow keys) instead. Some of the examples here use only the keyboard. All the models can be altered to use only the keyboard. For serious experimentation, get a joystick.

  4. You are going to have to learn some new things in order to work with Juice, but if you know a little about computers already, it will be quite simple. It also helps if you have some CAD experience.

General comments

Juice offers very little in terms of 3-D modeling effects. You must use very simple shapes to build your models, all of them symmetrical: Boxes, cylinders, or balls. These are collectively called "Beams" in Juice. A Juice model is an assembly of "beams" held together by joints.

These simple ingredients can be used to design models of highly complex real things.

The purpose of Juice simulation is to introduce motion into an assembly. This can only happen as a result of forces. There is one external force that is always available, gravity. Other forces are internal to the simulation, provided by motors that you design. The total momentum of a simulation cannot change as a result of internal forces, so that when a force acts, it causes an equal and opposite reaction. We observe this in Juice as the relative motion of the bodies, or "beams" in the model. One exception to this is the Juice ground plane, which is fixed. A moving object that hits the ground plane will rebound with full conservation of momentum. Friction between a moving object and the ground plane will dissipate energy. Juice does not keep account of energy.

Simulation

There are two phases to a simulation:

  1. The design. A model is built by design, (a) to specify an initial configuration of things (beams), their location in space, and how they are joined, and (b) to specify the motors that initiate motion.

  2. The action. This is not continuous, but like a movie it consists of a sequence of static frames, or time slices that follow each other rapidly.

    When you click the "Play" button, the design configuration will be updated, taking all forces into consideration.

    In each frame the computer calculates the positions and accelerations of the parts of the model to produce a new frame with new positions. The 3D image on the screen is updated, and the process repeats. Time, however, is continuous in reality. It is important to understand that the positions are calculated only on the basis of forces acting at the instant when time is sliced: If there are no forces acting, there will be no change of position. The time slices are also critical for the "truth" of the simulation.

    Juice does not simulate in real time. That is, on the whole the number of calculations required to specify a frame is so large that it takes longer than the duration of the slice. So the simulation "plays" only parts of the real motion that would occur in true physical objects. Juice might miss physical changes that would occur while it is busy calculating the next frame, especially if the time slices are quite large. As a result, a model could behave unrealistically. At worst, parts that are joined can "explode", or fly off into space. At best, the simulation may be "untruthful" in a way that is hard to detect. This is the question of validity that will be addressed in a separate section.

    The best way to ensure a realistic simulation is to run it in slow motion. That is, to use many very small time slices so that you stick close to the continuous changes in forces that occur, with less chance of missing something. The result is a realistic model that looks "unrealistic" in the sense that it does not move at true speed. However, the real "truth" of such a model will be enhanced.

  3. Most simulations do not occur in two phases: You generally have to repeat the above two steps many, many times. In addition, you may need to alter the model parameters (see below) to improve the simulation in some way.

Example

 An example model is given here for a quick introduction. The Juice file can be downloaded and studied in more detail.

Note: You cannot do anything with the Juice source file unless you have installed Juice.

  1. Pendulum.

    This is a very simple example. When you play it, you may have to rotate the 3D view to see it better. Click in the 3D view window, and use the up and down arrows on the keyboard to rotate it, page up and down to zoom in and out, or else click both mouse buttons together and drag the view to rotate it, or use the scroll button to zoom in or out.

    Comments on model: The pendulum is set in motion by a falling sphere, which strikes the bob of the pendulum at an angle. The sphere rolls off into the distance, and the pendulum swings. Note that there is no physical link between the pendulum bob and its fulcrum (red). In Juice all that is required is to specify the relative position of the mass (the bob) and the point about which it can move (the fulcrum). The model design positions the sphere at a vertical height above the ground plane, and it will remain at that location until the "Play" button is clicked. The force of gravity takes care of the rest.

Model design

Beams

There is a fourth shape, the Capsule that is basically a cylinder with rounded ends.

A wheel in Juice is best modeled as a disk. I prefer to use the capsule for the vehicle body because it is the only shape that looks a bit streamlined!

Further Notes:

Motion: Joints

The relative position of one beam to another is similarly specified and can change dynamically, but it can also be constrained by use of joints. There are three types of joints: Hinges, sliders, ball joints.

Tip: Think of joints as constraints on the motion of beams, not as physical components of the model.

  1. If two beams are joined with a hinge, then their relative position is constrained so they can only rotate about that hinge (but they can move anywhere else in absolute terms). An Axle is modeled as a shaft with a disk and a hinge at its center: The wheel can rotate 360 deg. about the shaft by means of the hinge. The disk will not be able to move in any other way relative to the shaft.

  2. A ball joint is like a hinge, but allows movement in two dimensions at once.

  3. A slider allows movement between two beams in one dimension only: Along the length of the slider.

Comments on Joints:

Dynamics

Gravity

The only way to start motion is with a force. Gravity is an external force always available to start motion. At the start of a simulation the beams are positioned as specified by the model design. If a mass is positioned above the ground plane and is unconstrained, then it will begin to fall immediately the "Play" button is clicked. If in doing so, it strikes another object, that will result in further motion. The pendulum examples listed below illustrate this plainly. That way, motion can result without any user control other than the initial design. Gravity may also be disabled, by setting the model parameter g to zero.

Motors

Internal forces originate from motors that you specify.

A motor is a joint that is the location of the application of a force. Therefore, think of motors as joints that have force enabled.

Behavior

 The control over motion by design involves a simple flow chart that specifies a motion source (a numeric constant, the keyboard, joystick, or main engine) and its destination (always a motor). In between, you can specify various functions such as multiplication, or adding a constant. For example, to control the rotation a beam through 180 degrees, you need to muliply the joystick output by 90, or using the main engine you must divide by two, and feed this into a position motor.

For vehicle simulation, it is easiest to use either a constant, or else a constant controlled by the joystick output. For example to drive a wheel, the axle (a hinge joint) must be given a velocity (speed) motor with input from the joystick multiplied by a suitable constant. The resulting speed will depend on both the joystick and the value of the multiplier.

Refer to the Juice online information on Network Behavior for a good explanation of this part of the simulation.

Other design aspects of dynamics

Model design includes two things that affect dynamics. Some of these things (in italics) are not fully understood:

  1. Mass: The mass of beams is specified in the design window, and directly influences dynamics.

  2. Gain and max force: Slider and hinge joints, when activated as motors, are the point of application of a force. You can limit this force by specification in the design.

    The gain on a joint is defined as the rate of change: desired velocity = (actual position - desired position) * gain). This is, according to the Juice technical documentation, under File Format. My understanding of this is in terms of "resilience": High gain makes a joint stiff, low gain makes it springy. For example, the steering can be made more "twitchy" by increasing the gain. That makes the steering change position rapidly in response to input. On the other hand, high gain also implies resistance to change by other forces acting at a joint. A steering joint with high gain will resist displacement by lateral inertia forces. With low gain there will be more self-steering.

    Note that the above only applies to joints that act as motors. Gain and max force have no effect on joints that cannot initiate motion. Therefore, a steering joint that is free to castor (with no motor), will never offer resistance irrespective of the gain and max force settings.

Basic Models

 Some models are given here as suggested "templates" for further development. The Juice files can be downloaded and studied in detail.

Important TIP: For steering the following models it helps to have good visual feedback (there is no feedback on a joystick like there is on a handlebar): Before you start Play, zoom in and rotate your model to get a good view (e.g. close-up of the front), then click on a prominent joint or frame member to select it, and then click Play. The selected object will remain in the center of the screen and in focus while the simulation runs its course.

Simple model control

Advanced steering control

  1. Free-tilting trike with countersteer. This is a tilting version of the trike above. Model control here is much more complex. The body is free to tilt about an axis near ground level, so it behaves like a virtual two-wheeler. To balance it requires countersteering just like the bike listed below. Note that both trikes and the bike are very similar in size and mass, etc.

    Comments on model: Countersteering on a (real) bike or motorcycle is a complex skill that requires feedback from the steering control and the vehicle tilt. It is almost impossible to do that with only visual feedback a joystick. Instead, this model uses automatic countersteering based on the built-in Juice body roll feedback. This is explained in detail below in the section on Advanced network behavior. Automatic countersteer is also implemented in the example of the James Patent trike, but there a purely mechanical linkage is used.

    There is a tendency to fall over at low speed, so it helps to start the model at full speed. Play it in slow motion with Max Delta = 5 if you have difficulty with the steering.

  2. Bike. This is a simple bicyle that is steered by controlling the front wheel with a joystick. The model control challenge here is more complex than for the trike.

    Comments on bike model: The steering here is similar to the trike above, but now includes a speed control as well: Just as on a real bike, at high speed more pressure is required on the handlebars to steer than at low speed. This is implemented with the Juice Advanced network behavior explained in more detail below.

    The model also includes a few obstacles scattered on the road surface, and part of the challenge is to steer the bike over these, and to observe what happens to the bike!

    There is a tendency to fall over at low speed, so it helps to start the model at full speed. Play the model with Max Delta = 5 (slow motion) if you have difficulty steering.

    Exercise:Try to add a pair of outriggers to this bike. See the outrigger example below for some suggestions on how to do it.

Advanced Network behaviour

You can produce very sophisticated control systems in Juice with the so-called network behaviour. The control can be edited somewhat like a flow diagram. Dynamic feedback loops can be included.

  1. Roll, pitch, yaw feedback. In a free-tilting vehicle at speed any steering input will cause the mass to tilt (roll). To balance a bike by steering alone for example, vehicle chassis roll angle is linked to the steering control:

    • In the Motion window, create a new motion source.
    • In the Properties window, click on the control source and pull down the list until you find Body Roll Feedback.
    • Click on Feedback source and then pick a beam that will act as source of the feedback. In the example below, the vehicle chassis (basically a block) was chosen as the feedback source. The vertical angle of this block is in direct relation to the vehicle roll.
    • In the Motion window, connect the newly created motion control source to a motor. In the example below, the control was linked to the steering joint, so that body roll would have a direct effect on the steering.
    • Various options can be used to tune the feedback, for example by adding an arithmetic node to increase the tilt-steering effect.

    If you set up the bike example like this (see file discussed above) with only body roll feedback to steer it, then it will carry on in a straight path without any intervention. Note what happens when it hits one of the beams in the path, and also note what happens if you delete the feedback and run it without any control!

  2. Discrepancy between actual and desired state. Most nodes can receive more than one input, and will automatically sum the inputs. If a node receives two inputs where one is negative and the other positive, the sum will be the difference. This simple fact allows you to control motion in terms of the difference between two things (in particular angles). For example, bike countersteering uses the discrepancy between steer angle and tilt angle. In a balanced, coordinated turn your steer angle exactly matches the amount of tilt required: You push against the handlebars to maintain the desired state.

    Note: To steer hard right (clockwise) you move the joystick X fully to the right (positive output of 1.0). However, the bike must also lean over to the right. At speed, steering right will cause body roll to the left (here body roll angle to left is negative - see below), and the bike will fall over immediately. Instead, with countersteering your steering is reversed(joystick output is multiplied by minus 5.0) causing the bike to tilt right (positive angle). Body roll feedback will now steer you in the desired direction (clockwise), which in turn will decrease tilt to the right. This loop repeats dynamically until an equilibrium state is achieved where body roll angle and actual steering angle match the desired steering angle.

  3. Note on Juice geometry. By default, forward orientation in space is along the Y-axis. All other angles and distances take that as reference. If a Juice model is oriented facing backwards along the Y-axis, then you must allow for this in designing controls.

  4. Flow control. The equilibrium state depends also on forward motion, and in fact at low speed we don't want countersteering. We can combine inputs from joystick X (tilt) and Y (throttle) as follows:

    • Note that here a so-called "multiplier" node is used to combine inputs multiplicatively. Other nodes combine inputs additively.
    • Also note that a multiplier can be used as an "on-off" switch: When it receives a value of zero from one input, the output from all other inputs is also zero. In this example, at zero speed (joystick Y at 0.0) joystick X has no effect on steering.
    • Fine tuning of the amount of tilt versus countersteer, etc. is achieved by altering the values of the so-called "arithmetic" nodes.

    Measures and Dimensions

     Juice is dimensionless in the sense that mass, position, size and force are not specified in any particular units of measure (such as kilograms, meters, etc). Angles are in degrees. The acceleration due to gravity is set at 9.81 by default, suggesting that all other dimensions are in meters and kilograms not feet or inches and pounds, for example. This matters little in practice, but obscures the relation between the model and reality in terms of scale. The example files included here are scaled quite small in absolute terms but if the dimensions are meters, then the bike has a wheelbase of 1.26 meters, which makes it full scale. The total mass is 105 units, which could be 105 kg and that is not unrealistic for a human-powered bicycle plus rider. Note: in the design you specify the mass, not the unit mass. I.e. "mass" refers to the total mass of a beam, not the mass per unit of volume.

    Simulation Parameters
    1. Juice simulations do not run in real time. The Juice menu item under General Options allows you to change the size of the time slices. The parameter Maximum delta controls this. A low value (e.g. 1 or 2) will produce the most accurate simulations in terms of how closely they follow the ideal behavior according to the laws of physics. This is because the simulation will be updated frequently, with only small gaps between each instant. High values of delta imply that the simulation is only updated relatively infrequently, and so physical changes may occur that are not reflected in the simulation. The result may be a departure from the laws of physics. The penalty you pay for low delta values is that motion is rendered very slowly (slow motion). With high delta values (20 or more) the visual simulation is closer to real time motion, but that may not be "true" realistic motion, as explained. This point is dealt with further in the section on validity.

    2. Juice Model parameters (Speed, Pose delay, Pose phase) are not of much importance for vehicle simulation because they apply to the main engine and its initiation.

    3. The Juice Dynamics library option seems only to work when set to Standard

    4. The Juice Physical constants includes two important parameter, the acceleration due to gravity and friction. The former can take any value since there are no dimensions in Juice, but for the sake of convention we use 9.81. Friction is troublesome. Theoretically, there are two coefficients of friction, static and sliding, while Juice allows only one. Moreover, a very wide range of values seems to work. This is a problem further dealt with in the next section.

    5. Bounce is the supposedly a coefficient of rebound. This has been found to have little effect on vehicle simulations, but may nevertheless be important. It is also dealt with in the next section, where a value of 1.00 is suggested.

    6. ERP and CFM are two parameters that can be used to "tweak" a simulation that is troublesome. Sometimes things go haywire (exploding models) and here you can eliminate such troubles. It has been suggested that ERP should be left close to 1.00, and that CFM should be kept low (e.g. .00005 or less). However, tweaking these parameters can be very time consuming and usually follows blind trial-and-error. For the sake of reliability (see below) it is important to attempt to keep these parameters fixed when comparing work by different users.

    Validity and Calibration

    More Examples
    Note on keyboard input: Some models can be played with the keyboard arrow keys to control steering if a joystick is not available. The keyboard left/right arrows are suitable, but operate as all-or-nothing, making it difficult to control. You can try "stabbing" the key rapidly to keep a constant input without holding the key down. When using the arrow keys during play, you must first get the window focus away from the 3D View window (the 3D view window frame must be grey - click your mouse on the Motion window for example), otherwise using the keys will change the 3D view angle instead of operating the steering.

    1. Phillip James 1987 Patent WO 8702951. This my rendition of the patent description (the original model was submitted by Alex "Der Zieher" from Berlin, but has been modified a great deal by myself).

      Comments on the model: The steering here is controlled by the joystick. This model has suspension, using Phillip's "ball spline" idea at the front. Here the orientation of the kingpins gives trail to the front wheels (in the models listed above this is done by offset only). Note the dimensions here are quite realistic. It is about 1.2 meters long and weighs about 180kg if you assume MKS dimension units. Note, the tilt-steer ratio is fixed in this version, not variable as it should really be. It seems to be quite manageable all the same (provided you have a joystick).

    2. "Pendulum" trike with FTC. This is a version of the so-called pendulum steering that has been much debated. A trike frame similar to basictrike.jm3 listed above, modified so the front wheel sweeps from side to side like a pendulum. This sweeping action is controlled by the joystick. Steering is automatic because the wheel is free to castor.

      Comments on model: Play this model with Max Delta = 5 to avoid problems with control.
    3. "Scully" bike with FTC (or FTC STV) . This is a bike version of the pendulum steering where the front wheel sweeps around a vertical axis. A bike frame similar to bike "stv3.jm3" listed above, modified so the front wheel sweeps from side to side. This sweeping action is controlled by the joystick. The wheel is free to castor. Pull the joystick back to accelerate.

      Comments on model: Play this model with Max Delta = 5 until you are familiar with the control. It should be "simple steer", i.e. no manual countersteering is required.
    4. Outriggers. The controversial issue of using outriggers on a TTW could perhaps be deal with by testing Juice models. This is left as an exercise for the reader: Take the basic bike model, and add a pair of wheels at the side, either in the middle, front, or rear. A simple outrigger "wheel" would be just a ball on an axle. Try position each ball at a height such that at 45 deg. tilt, the vehicle lands on the outrigger (the axle of each ball should then be oriented at 45 deg. also). The following file is just a bike, running with a fixed steering and throttle, so after a short while it will fall over. See what you can do to improve it with outriggers:

      Important note: This model is oriented along the X-axis, to avoid the problem of "floating joints" (see more on this below). Note further that when oriented along the X-axis you cannot use the symmetrical editing feature in Juice.

    5. Weird experiment. This shows a number of useful things for vehicle simulation. Notably, this model has an extremely high center of gravity (you must zoom out to see the body capsule high up), and a relatively narrow track width, also for experimentation. The steering is free-to-castor, and the only control is on the tilt angle, which is forced by the diagonal slider joint (in pink) inside the parallelogram frame. Keyboard input is used, and despite that limitation the model is surprisingly easy to control.

      Comments on model: Instead of using disks for wheels, here we have spheres. In Juice it is impossible to have a true round tyre profile suitable for a tilting vehicle, and these "spherical wheels" offer an alternative. The front disk "wheels" are for visual appearance only and do not touch the ground. Without the normal large rotating wheels, there is no gyroscopic effect. For that reason this model has two additional "wheels" that rotate without making contact with the road surface in order to add a gyroscopic force. Their speed of rotation can also be set independently of road speed, allowing further experimentation.

    Unanswered Questions

    1. Tyre Profile

      It is very frustrating to find that Juice does not allow you to make a proper tyre for your wheels. You can model a wheel as a thin disk, but you cannot give it a rounded profile. For a real tilting vehicle this matters - don't put flat profile car tyres on a motorbike! So in Juice, if you want to avoid a flat cross-section, you either make the disk so thin that it becomes a knife-edge, or else you can use a sphere. Both these solutions have disadvantages, but it is unclear how seriously that will affect your simulation.

    2. Floating Joints

      Hinges: Sometimes when you design a hinge to sit at a 45 degree roll angle, for example, you will find that when you play the simulation, the hinge immediately rolls to -45 degrees, so the orientation is out by 90 degrees. You can fix this by designing it at -45 and then it will play correctly at 45 degrees. However, it is unclear if this solution has any effect on the model as a whole. It applies only to roll. By default roll occurs about the Y-axis.

      A solution is to re-orient the model along the X-axis instead of the Y-axis. That way, default forward motion is along the X-axis, and for some unknown reason hinges stay in their place! See the outriggers example above for a bike that is oriented along the X-axis.

      Sliders: A similar thing may happen with slider joints: Sometimes they move to a different location immediately you click Play. I have found no solution to this, but it seems this is not a serious fault because the orientation of the sliders does not change when they go astray. Therefore, there should be no change in behaviour of the joint. The constraint imposed by a slider is unaffected by its actual location, only by its orientation.

    3. Friction

      It seems that Juice does not correctly simulate static friction. For example, place a block on the ground and apply a variable horizontal force. You will find that even with the slightest force, the block begins to slide. In reality, static friction will prevent movement if the applied force is too small to overcome friction force. It is unclear how this affects vehicle simulations.

    4. More questions ..? Let me know if you have any.

    Contact Information

    Please mail suggestions, questions, corrections, etc to: frank@tilting.org.za

    Frank Bokhorst.

    Page created: 2007
    Last updated: June 2020