Vehicle Simulator - VTR / RTR

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

blog entry #1

blog #2

blog #3

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.

The project was inspired by a request from element14 to team up with Texas Instruments, Cisco and element14 who are all interested in supporting development of an open source vehicle simulator.

Shabaz put together a great introduction to the project here.

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

I have been fortunate in being able to convince a software guru friend of mine to team up with me on this project. "Bob" is uncomfortable with my use of the term guru to describe him, but facts are facts. 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.

Project Status

Currently ordering parts and designing the cape.

Hopefully enough hardware will arrive to start posting pictures soon.

See blog #2 for an update

See also Blog#3

Vehicle Simulator Project - update

If anyone in the community would like to see other features, we are open to suggestions.