Infotainment Navigation Test Monitor

The Origin Story

Background

Bosch has been known for research and development in the field of audio entertainment systems from as early as 1932, and throughout the years they have managed to develop many modules. These modules have been incorporated with traffic and road information features.

Their current Infotainment system, combining more than your average audio, video and navigation systems, their Infotainment system links multiple features such as: entertainment, navigation, communication and operating functions. This system stands out from the other products in the market due to its options and features that can be expanded further by simply adding applications similar to a smartphone. It is an extremely user friendly system that uses natural human voice input without having to memorize particular commands, providing a safer and unique driving experience. To maintain and build upon such a platform, extensive testing must be done, especially concerning the on-road experience.

Project Solution

Basic Hardware Design

To go into further detail, the system described required four different cameras placed within vehicle. Two cameras focused on areas inside the vehicle; specifically, on the instrument cluster, located just behind the steering wheel, and one to monitor the center stack display, located on the main dashboard. These two would be intended to monitor and detect any errors occurring on the displays, as a result of software or as a result of human error. Two other cameras were intended to be placed on the dashboard facing outside the vehicle. These cameras were intended as a way to see what the driver is seeing and as a second way of confirming the information on the display - more specifically navigational information and instructions.

The data recorded by these cameras are intended to document any GPS, software, or human errors made resulting in system errors, as part of the testing process. Therefore, the cameras would expected to be recording simultaneously while the testing is taking place. Aside from the video being recorded, the system was also expected to have a way to monitor audio issues that may arise during the on-road testing.

Car showing the locations of the cameras

Synced according to the timestamp, the solution also included a GPS position tracker to record the vehicle’s location and displayed on the recorded video data. For data mobility, all of the information accumulated during the on-road test was expected to be saved on a storage device. It was decided that a USB drive would be the optimal medium used to save this data, as it could be removed from the device and would be compatible with most computers, though this also meant that the data must be compressed into a manageable file size. As this was apart of the current monitoring solution used by our customer, it was also agreed that for process assimilation, this method would allow for a more seamless implementation of our solution.

As a the workhorse of the solution, it was agreed that a microcontroller or microcontrollers be used. As part of the requirements, this or these microcontroller system(s) should be able to have the processing power to accomplish what was listed above and be able to operate on low power. For a flagging system, our team decided that a single button to flag the system, based on the timestamp, would be acceptable. For post processing, videos were expected to compile all four streams of recorded video data, the audio data, the GPS text data, and the timestamping information and compile them into one file, which would then be saved and exported, using the USB described above.

Top View of Odroid XU

Together, the external design is as such; a main box containing the microcontroller and a collection of peripheral components. These peripheral components, consisting of the four web cameras, the USB GPS, keypad, and USB storage solution, would be connected either directly to the microcontroller or connected to a USB hub.