You are on page 1of 25

Vehicle Simulator - VTR / RTR

Virtual Trip Runner (VTR) and Real Trip Recorder (RTR)

This project is an attempt to develop an open source vehicle simulator for use by anyone needing realistic
vehicle data delivered as it would be in a real vehicle.

A little additional perspective:

When thinking about how the internet-of-things will evolve, it is easy to predict vehicles will be a
significant focal point for consumer applications, since vehicles currently represent by far the biggest
technology expenditure/investment by the average consumer. Vehicles are very complex machines
incorporating multiple microcontrollers communicating via on-board busses. The level of electronic
technology in vehicles has exploded and there is a large amount of vehicle data readily available on the
diagnostic bus which is used locally, but not yet used for the vast number of potential external
applications.

There will be whole sectors of applications such as:

safer driver operation of the vehicle, fewer distractions, more automation


more effective driving methods
ways to get from A to B faster and safer
ways to save fuel
safer mechanical performance, better & more timely maintenance warnings
lower cost operation and lower maintenance costs
better and more timely driver information
better advanced traffic warnings and route planning
vehicles better designed to address owner needs and habits
accident response applications
vehicle-to-internet applications
vehicle-to-vehicle communications
applications that use data from multiple vehicles

The list goes far beyond the few obvious sectors listed here, but clearly there will be an enormous
number of vehicle-related internet-of-things applications.

Clearly development tools that allow development to take place in a lab will enable developers to develop
their applications and products faster, in a safer environment and at a lower cost.
Project Team

Fortunate in being able to convince a software guru friend of mine to team up with me on this project.
Team schedules will complicate logistics and blogging efforts, but the project will benefit immensely as he
is a much better software magician than me. He isn't keen on blogging so that will be one of my
responsibilities.

Initial Simulator Concept

Initially the system will need to be able to provide OBD2 data just as a real vehicle would in response to
queries on a CAN bus or K-Line interface. To ensure realistic data, trip data will be collected from real
vehicles the project will include a data collection system (Real Trip Recorder - RTR) as well as a playback
/ simulation system (Virtual Trip Runner - VTR). During a simulated trip, previously recorded data can be
interpolated to provide appropriate data to any bus queries.

Fault code simulation will be initially implemented on a best guess basis as we will not be able to create
and monitor real faults in real vehicles.

An attempt will be made to keep the software modular enough that it won't be difficult to replace fault
code simulations with better simulations when more is understood about their behaviour and also to
replace recorded trip scenarios with computed simulations, if and when they get developed.

Objectives:

1. The primary objective for this project is to provide a vehicle simulator system that provides realistic
enough data, primarily in electronic form, to allow developers to test their OBD2 reader prototypes & data
applications in a lab instead of needing to test in a vehicle.
1. The VTR system should provide some ability to generate fault codes
2. An secondary objective is to make the vehicle simulator such that it can be used to demonstrate new
products and applications indoors at trade shows or sales presentations.
3. A third objective is to make the vehicle simulation system a modular platform that can be extended and
upgraded to become a more accurate simulation for more vehicles.
4. An auxiliary objective is to create a data collection system that will continuously query a vehicle during a
trip and record real data with time stamps.
System Platform:

In order to make a compact open system that can be easily setup for testing or demonstration at any
location the Beaglebone Black (BBB) has been chosen as the platform. Several of them are being
supplied by the project sponsors Texas Instruments, Cisco and element14. This will allow a data
collection system (RTR) to collect trip data from a real vehicle, then a simulator system (VTR) can
simulate this trip for the same data collection unit to see if it collects the same data from the simulation as
it did from the real trip. This dual system provides an easy way to validate the system.

A single system will be able to function as either a trip recorder or a simulator.

System Design:

OBD2 data provides a lot of information about what is occurring inside vehicle systems, but it does not
necessarily provide everything desired in a simulation, such as location and orientation of the vehicle,
distance travelled, and time stamps on all data.

The Beaglebone Black (BBB) has a CAN bus capability, but a custom cape will be needed to translate
this to OBD2 signals and add in a K-Line interface. This cape will also include a GPS module and a 10
channel sensor suite - 3 orthogonal linear accelerometers, 3 orthogonal angular rate sensors, 3
orthogonal magnetometers and an absolute pressure sensor. These sensors are not needed in the
simulator system (VTR), but will allow more sophisticated sensor data to be collected when the device is
used for recording real trips (RTR) and this data can later be presented by the simulator (VTR). The
VTR/RTR cape will also include a Bluetooth module - when in VTR mode it will allow generation of fault
codes and control of the VTR from a smart phone, when in RTR mode it will allow connection to a
Bluetooth OBD2 interface or possibly a smart phone.

Since the RTR will have a full OBD2 interface, either wired or wireless, there is no reason it couldn't be
used to reset fault codes, however this feature will likely not be included in the first software release.
RTR Block Diagram
VTR Block Diagram
Trip Video

Initially it should be easy to record video of a trip while electronic data is being collected using a separate
video camcorder. Having the simulator play it back in proper sync is a bit of an unknown right now, but
obviously it could be played on a separate player while the simulation is running. Ultimately it may be
possible to record and playback video on the same Beaglebone platform, but this functionality is not a
target for the first release.

Project Plan

1. The first major task is to set up 2 Beaglebone Blacks (BBB) to communicate with each other over a CAN
bus. This will allow us to gain an understanding of CAN bus messages and protocol. There are a bunch of
associated subtasks such as obtaining appropriate hardware, organizing software development tools,
researching what is available on open source, writing some test code, etc.
2. Design, build and test an OBD2 cape for the BBB.
3. Connect a BBB to a vehicle and send and receive OBD2 messages.
4. Write the RTR data collection firmware.
5. Write VTR simulation firmware.
6. Test and validate system.
Vehicle Simulation System Project
This post is to help explain a new project which could be extremely useful for the community. If youve
ever been stuck in a traffic jam, or broken down, or wanted to know the health of your car, and wanted to
do something about it, then this open source project will resonate with you.

As you probably know, most vehicles nowadays have an On-Board Diagnostic (OBD) connector which is
wired up to the cars internal computer. It is used in many garages where the mechanic can probe the car
through the OBD connector and read out parameters onto a display.

In an Internet of Things (IoT) world where the car can be easily connected to the Internet (perhaps via
Bluetooth to a smartphone), it could automatically search an online knowledge base and not only report a
fault code but also let you know the most likely cause either based on the cars personal history or on the
environment (an expert system could conclude it is minus 15 degrees Celsius outside, and there is a
water leak, and it is likely to be a cracked hose due to the cold temperature and there was a
manufacturer recall notice concerning this hose). All this could occur before you visit a mechanic. It could
proactively detect issues from engine coolant temperature or oxygen sensor readings. It could work with
nearly all cars in use today.
As another example, if people were prepared to send anonymous data concerning their vehicle speed,
then traffic reports could become more accurate not only for immediate use but also for longer term road
planning decisions. Fairer vehicle taxation based on vehicle usage could be another possibility.

All these things involving vehicles, sensors and communications (telematics) would have been expensive
and impractical to implement in the past on a mass market scale.

Today, the explosion of low-cost 3G/4G mobile connectivity, smartphones and cloud computing provide a
unique opportunity for people. Designers can work on sensor technology within the car, and get deep
measurements from the OBD connector. Other developers can work on exposing this rich information
through smartphone apps as an example. Some companies are working on IoT middleware, running on a
cloud based platform, to allow yet others to create end applications that can make use of the data. It will
become possible to subscribe to the data (with permission and a fee or benefit for the car owner) and
build applications that can make use of the sensor data.

The diagram here shows how vehicle data could be transferred wirelessly to a mobile phone which then
connects to a cloud software service.
One major issue today is that people who have ideas for such vehicle applications will have to test their
prototypes by physically connecting to the OBD port of various vehicles to get the data and be able to test
their software and hardware.

This is a risky thing to do early prototype hardware could be unsafe and furthermore no-one wants to
drive their car while keeping an eye on their untested microcontroller board project that theyve plugged
into the car. In addition one car may behave very differently compared to another car. It slows
development tremendously.

One way to work toward a solution is to create a system which can simulate a car. To all intents and
purposes, under certain conditions, it should behave exactly like a real vehicle would, only in the comfort
of a lab rather than a garage.

It could become possible to apply vehicle and journey simulation data-sets, or even make adjustments on
a screen to simulate car speed and faults. One minute testing could be done with a Honda simulation,
and in the next minute it could become a Hyundai.
The vehicle simulator could be taken to shows and exhibitions, and used to demonstrate new telematics
offerings, without needing a real car nearby. People could adjust the simulated accelerator or change
gear on a tablet display, and immediately see the impact.

Possibly, there is a lot of money to be made designing systems that could be sold to local governments to
hand out to residents who complain of traffic hotspots. If you want to pitch a solution to a government
representative, it is hard to do that when the car that is needed for the demonstration is in the parking
garage. A compact vehicle simulator connected to a tablet displaying a graphical dashboard would be the
better idea.

As another concept, computer games could become extremely realistic, with a simulation down to such a
detailed level. Such a simulation may be useful for rallying drivers, using datasets and models derived
from real vehicles. There are many possibilities that have not been thought of.

This project proposes an open source vehicle simulation tool to allow the Element 14 community and
beyond to build applications rapidly without requiring actual vehicles for much of the testing. Open source
will allow people to enhance the design over time so that it can simulate more and more parameters until
it can be highly refined to meet many needs.
Today there are some commercial vehicle simulation systems out there, but they tend to be boxes with a
small microcontroller and a few control knobs on them for limited parameters such as speed, and
temperature.

It would be better to have a compact, modern Linux-based vehicle simulator with capability to be
controlled from a mobile phone or tablet screen for highly visual and detailed simulations, and it would be
great to see the community here advance this.
Vehicle Simulator Project

This is an update to the initial blog on a vehicle simulator here:

This simulator looks like an operating vehicle to any instrumentation or application that can interface to a
normal vehicle via its OBDII connector. The data supplied by the simulator is real trip data collected by
the Trip Recorder function of the system. There is additional sensor data available that is collected
directly from the Car Cape sensor suite during the same reference trips, such as GPS position, compass
heading, accelerations, angular rates, barometric pressure, temperature and ambient light.

The system is built around a Beaglebone Black with a "Car Cape" mounted on it to provide an OBDII
interface, a sensor suite, a user interface and a wireless communications interface. The system may be
used as either a simulator or as a stand-alone trip recorder.

Since the introductory blog, we have been busy designing hardware, ordering parts and building
hardware. We have also been setting up a Beaglebone Black development environment and configuring
an operating system build and experimenting with CAN bus communications.

Status

We have built 3 capes with CAN bus capability and a suite of functionality appropriate for our vehicle
applications. The various features are outlined in bullets around the Car Cape image below.

The software and hardware are currently functional enough for 2 Beaglebone Blacks, with installed
capes, to communicate over the CAN bus.

Not shown are a separate keypad card and a separate OBDII connector card which also has a DC-DC
converter to supply 5 volts the BBBs. These cards are built, but not fully tested yet.
Vehicle Simulator Project - update

This update shows the Car Cape running on a Beaglebone Black.

Both vehicle simulator and vehicle recorder systems have been built and they communicate with each
other fine over the CAN bus.

We are still having a devil of a time sorting out OBDII communications with a real vehicle. This is the main
reason for such a long delay since our last posting, however I figured we need to post at least an update.

So far there are 6 screens to display sensor data from the sensors on the Car Cape.

We have not spent much time on these as the OBDII interface has been taking so much time.

Here are some screen shots to give some idea of what they look like:
This screen shows location coordinates when the GPS finds enough satellites. Right now it is still
showing UTC time.
This is a little warm because I have some bright lights shining directly on the module.
We are still sorting out some of the analog channels...
The LCD updates "instantly" in response to the keypad scroll buttons because it is interfaced via SPI.

The following video demonstrates how quickly the LCD repaints after each scroll button push:
Here is a picture showing the card stack making up the vehicle simulator/recorder module:
Right now we are analyzing commercial OBDII readers like the one shown above to determine how to
handle vehicle communications properly.
Quick update:

We have started using one of these CAN bus interfaces to help analyze what is going on with the CAN /
OBD2 bus:

This module is helping significantly at this stage to get us over an impasse.

The 2 BBB modules communicate with each other.

The 2 BBBs can communicate fine with the USB-CAN module above.

The commercial reader can also communicate fine with the USB-CAN module.

The commercial reader does not communicate with either BBB.

It seems they somehow think the frames are invalid.

Unfortunately my software partner is away for a month starting today, and the rig is at his place, so further
updates will be delayed for a month.

You might also like