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
- Getting Started with Juice
- Requirements (Hardware and Software)
- General comments
- Multiple phases
- A Pendulum
- Non-tilting Trike
- Model design
- Slider motors and hinge motors
- Motor control
- Sources of motion
- Juice main engine
- Other design aspects of dynamics
- Basic Models
- Simple model control
- Non-tilting trike
- Gyroscope effects
- Advanced steering control
- Advanced Network behaviour
- Roll, pitch and yaw feedback
- Combining inputs
- Measures and Dimensions
- Simulation Parameters
- General Options: Maximum delta
- Model parameters (Speed, Pose delay, Pose phase)
- Dynamics library
- Physical constants
- ERP and CFM
- Validity and Calibration
- DETERMINE SETTING FOR REBOUND THAT GIVES PERFECT TRANSFER OF ENERGY
- CALIBRATE FRICTION
- More Examples
- Phillip James 1987 Patent WO 8702951
- "Pendulum" trike with FTC
- Weird experiment
- Unanswered questions
- Tyre profiles
- Floating joints
- Contact information
Getting Started with Juice
- 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.
- Juice does not need much computer power. You can run it without any special hardware.
- 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.
- 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.
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.
There are two phases to a simulation:
- 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.
- 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.
- 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.
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.
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.
- A BOX can be square or rectangular, with any ratio of height, to width, to length. E.g. a flat sheet is basically modeled as a very thin box.
- A CYLINDER can be any length, or ratio of length to diameter. So for example, a disk is simply a very short cylinder.
- A BALL is just a round object of any diameter.
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!
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.
- 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.
- A ball joint is like a hinge, but allows movement in two dimensions at once.
- A slider allows movement between two beams in one dimension only: Along the length of the slider.
Comments on Joints:
- Note: All these joints are frictionless! In Juice friction only applies between two solid surfaces that are in contact.
- These joints do not require contact either between the two beams, or between the joints and the beams being joined.
- A joint has a location in space, but occupies no space. Therefore, a solid wheel can have a hinge "inside" it, acting as bearing. The fact that a joint can be seen is only to indicate its position in space. Or, two joints can occupy the same space. Joints also have no mass. They are not objects, but points in space (ball joints) or lines with orientation but no width (hinges and sliders).
- A joint can only join two beams. You cannot join three beams with one joint. If you want to do that, you must put a second joint at the same place as the first.
- Joints are for simulating motion. If you want to join two beams to prevent motion, then you must place two joints in such a manner that motion is physically impossible (e.g. two hinges at right angle). You can have more than one joint on a single beam. This is shown in the pedulum example above.
- While joints themselves are frictionless, a joint that is a motor (see below) will always produce a torque even when the motor is stationary. A stationary motor will act as a brake, or can be used as a damper. Use a motor if you want to restrain a joint. However, the torque cannot be varied. This has implications for certain steering controls. For example a motorcycle is controlled by applying a torque to the handlebars, which requires a motor in Juice, but then the model cannot be run with no steering input (i.e. "hands off" the handlebars). Motorcycle steering is discussed further below.
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.
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.
- Slider motors can exert linear force, while hinge motors exert torque. There is no other way (except to drag an object with the mouse - which is cheating) to apply a force while a simulation is playing. All motion is the result of the conservation of momentum within the simulation.
- A motor can alter either the speed or else the position of two beams relative to each other. To achieve this, force is required. If the available force is not sufficient, nothing will happen. Maximum available force can be specified in the model design.
- Motors can be controlled by design, or can be varied by an external control device (either the keyboard or a joystick). Control varies either the speed or the position depending on choice of design.
While playing, you have no direct control over magnitude of force. However, to increase speed torque must increase, therefore speed control appears to be the same as torque control.
The keyboard and joystick can be thought of as sources of motion. The output of the keyboard is either -1, zero, or else +1, and the joystick output varies continuously from +1.00 to -1.00. These numeric values are used by the model designer to control (by multiplication) the behavior of a motor (see section on behavior below).
- The so-called Juice main engine is not a motor. Instead, it is a source of motion, or control device. It has an output that cycles from 0 to 360 continuously. If this is fed into a joint activated as a position motor, then it will produce rotation. When fed into a slider, it will produce a "piston" cyclic linear motion. The speed at which the main engine cycles is controlled by the model parameters (there is also a control on the window interface).
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:
- Mass: The mass of beams is specified in the design window, and directly influences dynamics.
- 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.
- TIP: If you want to make a resilient joint, then define it as a motor and give it a constant input of zero. Use the max force and gain settings to stiffen the spring. It is unclear what the difference between position and velocity type motors is in this regard.
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
This is a non-tilting three-wheeler that is steered by controlling the front wheel with a joystick.
Comments on trike: The throttle (speed control) operates by pulling the joystick back. Moving it left - right will steer the trike. You can steer it to ride up on two wheels. At high speed (it takes a little while to accelerate) it can be easily tipped right over.
Note the construction of the rear cross-beam, which is attached to the body by two "pegs" which are really hinges. However, this is only included for the sake of visual appearance. The wheels could just as well be attached directly to the body, without even having the straight axle between the wheels. The front steering axis is located in space without "touching" the body, but remember - joints are not objects, they only specify a constraint at a certain position. The front "fork" is a single beam located "inside" the wheel. This is possible in Juice: The two parts do not collide, so you can get away with it. Actually the position of the beam does not matter - it could also be located at the side of the wheel. The positioning and orientation of the joints is crucial, however. More about this below - be patient!
If you have difficulty controlling it, play it with Max Delta = 5 (slow motion).
- Gyroscopic steering.
This is a testbed for exploring gyroscopic steering effects. There is a free-to-castor wheel mounted on a tilting assembly. When the wheel is tilted, it steers automatically. You can modify the model to test various parameters.
Comments on model: Keyboard left/right keys turn the "steering" here, while joystick fore-aft controls gyro speed. Works without joystick also, but at the minimum speed. You can of course set the speed with a constant as input instead of the joystick (see illustration below). Note the very high mass of the base, required to stabilize the model against inertia reactions.
Advanced steering control
- 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.
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.
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
- The Juice Dynamics library option seems only to work when set to Standard
- 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.
- 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.
- 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
- The above comments highlight the degree to which a Juice simulation resembles real physical phenomena. This was mentioned earlier as a question of "truth" which is something undefined, so I put it in quotes.
The term validity can be defined as the degree to which the model approximates reality, and is preferable.
By definition, Juice uses only the laws of physics to run a simulation, so it should be true to reality insofar as these laws describe reality. However, there are inevitable shorcuts and gaps in the implementation of these laws by Juice - the simulation will be a simplified version of reality. Does that lead to an unacceptable departure from reality? One way to test this is to look at simple physical phenomena that are well understood. Some tests have been attempted, and are described below for others to try.
The pedulum is very simple and well-defined. The first example given at the top of this page gives an indication of validity: The pedulum is set in motion by a known mass falling from a known height. Theoretically one could calculate the deflection of the pendulum and compare that with the actual deflection produced by Juice. Further, if there is no friction in the pendulum hinge joint, then it should swing forever.
- A related question is about calibration. Aaron Davenport raised this, and provided some very useful suggestions for how to deal with it. This is most important when comparing simulations by different users of Juice. Particularly troublesome here is the fact that users will be trying variations on the model parameters mentioned above, and so get results that are incomparable. To overcome that, Aaron proposed some tests that could be used to calibrate Juice.
N.B. When running the following tests, to get "true" results you must set the value of Max Delta (see Simulation Parameters above) to 1. The tests will run very slowly, but that will ensure that the computation is as accurate as possible. For example, in the case of the pendulum mentioned earlier, it will only continue to swing to the same height when Max Delta = 1.
- DETERMINE SETTING FOR REBOUND THAT GIVES PERFECT TRANSFER OF ENERGY (ie. object travelling 1m/s strikes stationary object which leaves at 1m/s).
- Create 1 unit mass cube (1 unit per side) on the end of a pendulum (no arm, just the ball a set distance from the pivot point).
- Set pendulum initial position at 90 degrees (horizontal to ground).
- Place an identical test pendulum adjacent to first pendulum so that test cubes will strike flat on a side at the bottom of swing.
- Let pendulum swing and adjust rebound setting so that first cube stops and second cube rises to same height as initial cube (horizontal) after impact. A marker or pointer can be set to judge height of second pendulum swing.
Click here to download Juice file test2.jm3 for this calibration test.
My Comment: Based on this test I find that Bounce = 1.00 gives the desired result.
Additional note: The CFM parameter in this model is set rather high at .001. If you change it to .0005 the result is better.
- CALIBRATE FRICTION
- Use test pendulum from previous test with only one arm and cube and rebound setting found above.
- Calculate height of pendulum to make cube travel known velocity (due to G) when it reaches the bottom of its swing (PE = KE).
- Set height of pivot so that cube almost touches the ground at bottom of its swing.
- Place second test cube on the ground adjacent to lowest swing position of pendulum. When run, first cube should drop from horizontal to vertical and stop after striking the second cube. This should insure that second cube is traveling at the same velocity as first.
- Calculate time for known friction applied to test area (1 square unit) and test mass to stop object traveling the known velocity. There's a LOT of possible friction choices, but I suggest probably rubber on pavement is the friction setting that will matter most to the tests that we want to do with Juice. We might want to keep friction settings for rubber on wet pavement and others similar for testing though.
- Run simulation and adjust friction constant until test cube stops in calculated time after impact.
Click here to download Juice file test3.jm3 for this calibration test.
My comments: In the implementation of this test you cannot use time as the measure because Juice does not run in real time. Using distance instead I calculated the coefficient of friction "mu" as follows (note that mu is unitless always):
Based on the notion that energy lost to
friction Ef can be equated to potential energy Ep,
if Ef = mu * normal force * distance and
Ep = g * mass * height then you can solve for
distance if mu is known, the height is known, and
the mass of both blocks is the same. This assumes
mu is not the static coefficient, and is independent
of area. I don't know how to handle the combination
of static and sliding friction. It seems Juice takes
both into consideration. In any case, my test
says it uses a coefficient approx. 2.0.
- Test static friction
The next model is a test I devised to observe static friction. It uses a weight, linked with a set of pulleys to move a block resting on the ground. It should be possible to find the mass that will just barely get the block to move.
Zoom in on the ball when you play this, and you can easily see if it moves. If the ball moves, so does the weight. Change the mass of the ball until it does not drop.
Use Max delta = 1 or 2 for most accurate observations. Note that you cannot enter a mass of less than .01.
Click here to download Juice file test4.jm3 for this.
Comments: I have found that at any setting, the block will always move. You will have to wait a long time, but finnaly the ball will touch the ground. It seems Juice does not implement static friction correctly.
- What value for Friction Parameter?
Since Juice does not seem to offer a definitive solution, it seems a rule of thumb may be most useful. In my experience with models of wheeled vehicles, the value 100 works quite realistically (sometimes the wheels begin to drift). At 200 there is hardly noticeable drifting, and a value of 400 should be considered high (like running very soft rubber compound). In the end, one should experiment to find high and low boundary values that can serve to determine a rough estimate.
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.
- 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).
- "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.
- "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.
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.
- 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.
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.
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.
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.
- More questions ..? Let me know if you have any.
Please mail suggestions, questions, corrections, etc to: firstname.lastname@example.org
Page created: 2007
Last updated: June 2020