Accurate Vehicle Simulation in Blender/Morse

I’ve been working with the Morse simulator for the last few weeks.  It has been really impressive so far but is missing a few key features I need.  Wheel slip is a major source of navigation error in GPS denied environments.  This is particularly true for tracked vehicles like the Matilda that I am using for my current research.  Wheel slip is difficult to simulate as it depends on complex models needing parameters such as vehicle weight, tire friction characteristics, ground characteristics, etc…  My original reasoning for using Morse over my current Matlab simulations was to be able to generate test data with more accurate wheel slip and side slip.

Vehicle Modeling Methods

From the research I’ve done the last few days it seems that there are three main methods for simulating a vehicle in Blender.

  1. Treat the vehicle as a box and move it by controlling its angular and linear velocities in Blender.
  2. Use the ‘Raycast Vehicle Constraint’ methods built into the Bullet physics engine.
  3. Model the chassis, wheels, and suspension components separately and connect them using physic constraints.

Only the third method seems to allow wheel slip to be simulated so I started with it.  Since I don’t have a good 3D model of the Matilda (anyone other there want to send me one?), I started testing by adding a model for a Segway RMP400, which we also have in the lab.  The mesh used is courtesy of Evan Jensen at Texas State University and is a lower polygon count version than the model available directly from Segway.

Physics Based Vehicle Modelling

Following the examples found at: and×4-vehicle-game-in-progress., the wheels are modeled as separate rigid bodies and are connected to the chassis using a 6DOF rigid body constraint.  The examples given also model suspension components, but currently I am just attaching the wheels rigidly to the body since there is no suspension on the Segway.  The Segway model with both the local wheel (left) and chassis (right) coordinate frames is shown in the image below:

Note that contrary to SAE standards, the y-axis points out the front of the vehicle.  The reason for this will be explained more below.  The python code for the physics constraints is given below:

joint = PhysicsConstraints.createConstraint( chassis.getPhysicsId(),           wheel.getPhysicsId(), # get physics ID of the wheel object           12, # 6dof constraint           wheelPos[0], wheelPos[1], wheelPos[2], # pivot position            0,0,0, # pivot axis           128) # flag, 128=disable collision between wheel and parent 

 # no parameters are set on x axis to allow full rotation about it joint.setParam(4,0.0,0.0) # no rotation about Y axis - min=0, max=0 joint.setParam(5,0.0,0.0) # no rotation about Z axis - min=0, max=0

The first line of code joins the given wheel object to the chassis object at the location given by wheelPos.  It is still free to rotate about every axis, however.  The following two lines constrain the rotation about the y and z axes to be between 0 radians and 0 radians, essentially locking rotation about that axis.  No limits are set on the x-axis as this is the axis the wheel will rotate about.  The syntax is explained further here:

Another setParam call can be made on the joint to rotate the wheel about the x-axis as shown below:


 The first parameter specifies the axis (x=9,y=10,z=11).  The second parameter is the desired angular velocity in rad/s and the third is the maximum force that can be applied to reach that angular velocity.  

Current Results

A video of the finished model integrated into Morse is available at:

The vehicle  seems to work fairly well, but definitely still have a few problems.  One is that the rigid body constraints don’t seem to always hold.  The wheels tilt slightly left and right when turning.  This can be seen most clearly when zig-zagging beginning at around 30 seconds in.  A similar behavior was reported in a post at:  The wheels also seem to twitch randomly causing the vehicle to have a “bumpy” ride and causing odd values in the wheel rotation data.

 The model does seem to give fairly realistic wheel slip values, although the slip appears to be larger than I would expect.  Changing the wheel and floor material friction values also has very little effect on the amount of slip.  An example plot is shown below.  The blue line is the percent wheel slip of the front right wheel with the floor friction set to 1.0 and the wheel friction set to 0.2.  The red plot has the wheel friction increased to 200.  The shapes of the plots are different since they were taken on two different runs, but the magnitudes are similar.  

Coordinate System Issues

As mentioned earlier, the local y-axis currently points out the front of the vehicle.  It would be preferable for the x-axis to point out the front as per SAE standards.  Rotating the chassis frame seems to cause problems with the 6DOF constraint, however.  Setting the chassis local x-axis to point out the front of the vehicle with the y-axis out the driver’s side and continuing to rotate the wheels about the x-axis results in the behavior seen in:

The obvious way to fix this would seem to be to change the constraints to rotate about the y-axis since it is now the vehicle axis that points toward the wheels, but for some reason this does not work and produces the erratic behavior seen in:

Things to Try

I’m currently working on trying to get rid of the wheel twitching seen in the first video and generate more realistic slip values.  Things I’m considering trying include:

  • Changing the wheel models to something more complicated than a cylinder (i.e. give some bevel to the sides of the wheels to allows them to move laterally better)
  • Adding anisotropic firction
  • Moving to the bge namespace constraints used in Blender 2.5 rather than the ones from the PhysicsConstraints namespace that were shown in the Blender 2.4 tutorial.


Posted in Blender, MORSE, Robot Modelling | 1 Comment

Morse Robotics Simulator and MOOS

A labmate (William Woodall) introduced me to an awesome new robotics simulator that is currently being developed called MORSE.  It runs on Blender and after trying USARSim and Microsoft Robotics Developer Studio, it is much easier to use and extend.  I’ve developed the beginnings of a middleware component for it to allow it to communicate with apps using the MOOS framework.  Currently it is capable of reading velocity and yaw rate commands from the database and using them to drive a vehicle and posting the output of any sensor to the database using a generic serialization method.  I’m currently working on adding the ability to specify custom database variable names for the MORSE sensor outputs.


Middlewares for MORSE are written in Python.  The pymoos Python MOOS interface code developed by Ian Baldwin was used to connect to the MOOS database.  MORSE and Blender require Python 3 and pymoos was written for Python 2.7 so it had to be modified slightly.  The modified code is available here: pymoos_py32.tar.  The pymoos code makes use of the Boost Python library which in the Ubuntu repository versions is compiled for Python 2.7.  The Boost Python library compiled with the ‘–with-python-version=3.2′ option is needed to use pymoos with MORSE.

The MOOS middleware currently consists of two components the ‘’ Python script and a ‘moos_empty.blend’ blender file.  An example ‘tutorial-1-solved_moos.blend’ as well as the two middleware components and the modified makefiles are available here: morse_with_moos.tar.gz.


I’ve created a fork of the morse git repository that contains my MOOS additions.  It is available at: git://  It is highly recommended to use this version rather than the above linked file.  The current git version has the generic parser listed above as well as specific parsers for the true simulation pose, lidar, gps, and imu sensors using the variable naming conventions used by our lab.  The variable names used to post the database could, however, be easily changed.


Posted in MOOS, MORSE, Software | 1 Comment

New site

I’m working on moving things from my Auburn website ( to here.  There’s not much here right now, but I’ll be updating it over the next few weeks.

Posted in Uncategorized | Leave a comment