WIRED Autopia slips into driver's seat of QNX reference vehicle

Chances are, you've seen pictures of the new QNX reference vehicle. You may have even seen the "making of" video that QNX released a few days ago. But have you seen any video of the vehicle in action?

If not, check out this vid by Doug Newcomb of WIRED Autopia. Last week, at Telematics Detroit, Doug met up with Andrew Poliak of QNX for a tour of the vehicle and its various features, including a re-skinnable UI and voice-controlled Facebook integration. The camera was rolling, and here's what it caught:


 

HTML5 brings new buzz to infotainment system development

QNX to unveil QNX CAR 2 platform on Freescale i.MX 6 at FTF Americas — a guest post from Paul Sykes of Freescale

If you’ve visited the QNX website recently or attended the Telematics Detroit conference last week, then you’ve surely noticed that HTML5 is getting a lot of attention in automotive these days. The buzz around HTML5 focuses on two areas: as an application development and delivery framework, and as an HMI framework. In discussions with many industry participants, my impression is that the application framework part is generally accepted, while the HMI framework part still isn’t well understood.

I don’t intend to discuss these HTML5 aspects in detail. There are experts within the ecosystem that can do a much better job than me. But I will say that Freescale applications processors will offer the processing and graphics performance to run the desired applications and bring the HMI to life with stunning graphics.

Next week, Freescale will host the annual FTF Americas event in San Antonio, TX. We are very excited about the first public unveiling of the QNX CAR 2 application platform on i.MX 6. Since QNX CAR 2 is based on HTML5, it is particularly fitting to mention in this blog. For those with an interest in understanding more about HTML5 for infotainment systems, QNX and many other ecosystem partners will be on hand at FTF to discuss their thoughts and plans.

Paul Sykes is a member of Freescale’s driver information systems team.
 

The making of the QNX reference vehicle: Jeep Wrangler

Guest post from Nicole Forget of QNX Software Systems

Nicole Forget

Just one week ago, our new reference vehicle was revealed at Telematics Detroit 2012. The Jeep Wrangler features QNX’s digital instrument cluster, which is totally re-skinnable. In fact, the entire user interface of the head unit, which was created using HTML5, can also be re-skinned. The head unit supports loads of functions, too, including the virtual mechanic, which are outlined in an earlier post.

The following video gives you some insight into the hard work that was put into the making of the reference vehicle. Check it out!


 

Moving beyond the browser: HTML5 as an automotive app environment

If you’ve already visited this blog, you’ll know that we are bullish on HTML5 as a way to implement infotainment system HMIs. Not surprisingly, I’ve spent a fair amount of time searching the Web for facts and opinions on using HTML5 in the car, to see how this idea is catching on.

Overall, people see numerous benefits, such as the ability to leverage mobile app development to keep pace with the consumer demands, the availability of a large pool of knowledgeable developers, and the attractiveness of a truly open specification supported by many possible vendors.

But when it comes to the challenges of making HTML5 a reality in the car, I found a common thread of questions, mostly rooted in the erroneous belief that an HTML5 application environment is “just a browser.” Everyone is familiar with the concept of a browser, so it’s easy to see why people take this point of view.

So what are the key differences between a browser and an HTML5 application environment? Here’s my quick view.

The experience
Everyone is familiar with the browser experience. You navigate to a web site through bookmarks, a search engine, or direct entry of a URL. The browser implements a user interface (aka the chrome) around a rendering engine and provides bookmarks, URL entry, back and forward, scrolling and panning, and other familiar features.

An automotive HMI based on HTML5 provides a different experience — just look at the accompanying screen shots and decide for yourself if they look like a browser. In fact, the user experience of an HTML5-based HMI is similar to that of any other purpose-built HMI. It can consist of a main screen, window management, navigation controls, and other typical user interface widgets.


A radio tuner and a media player from the QNX CAR 2 application platform. Both apps are based on HTML5, but beyond that, they neither act nor look like a web browser.

A system that uses an HTML5-based HMI can include:

• core applications that look and act like native applications
   
• add-on (downloaded and installed) applications that have controlled interfaces to the underlying hardware
   
• “web link” applications that simply link to a cloud-hosted application that can be downloaded on demand and cached

The web link approach makes it easy to update applications: just update the server and the remote client systems will automatically pull the application when needed.

Local resources
Web browsers pull text, images, and other content from the web and render it on the user’s machine. The process of loading this remote content accounts for much of the user’s wait time. This paradigm changes with a local HTML5 application environment — because resources can exist locally, images and other components can load much more quickly.

What’s more, screens and user interfaces can be designed to fit the platform’s display characteristics. There is no need for panning and scrolling, and only limited need for zooming. Resources such as RAM can be optimized for this experience.

Security and sandboxing
Browsers load content and executable JavaScript code dynamically. This really is the power of the web technologies. The problem is, dynamically loaded code represents a threat to an embedded platform.

Browsers are designed to be sandboxed. By default, JavaScript code can execute only in the context of a browser engine, and cannot access the underlying operating system primitives and hardware. This approach changes in an HTML5 application environment. To give JavaScript code the ability to behave like a native application, the environment needs interfaces to the underlying OS through to the hardware. Plugins are used to implement these HTML5-to-OS interfaces.

Nonetheless, access to the underlying platform must be carefully controlled. Hence, a security scheme forms a critical component of the HTML5 application environment.

Application packaging
The app experience has become familiar to anyone who owns a smartphone or tablet. An HTML5 application environment in the car can also support this kind of experience: developers create and sign application packages, and users can download those packages from an application store. In an automotive context, authenticity of the applications and control over what they can or cannot do is critical. Again, a security model that enforces this forms a key part of the HTML5 application environment.

So, how should you think of an HTML5 application environment?
From my perspective, an HTML5 environment is like any other traditional HMI toolkit, but with much more flexibility and with inherent support for connected applications. In an HTML5 application environment, you can find technologies similar to those of any proprietary toolkit, including:

• a rendering engine (HTML5 rendering engine)
• a set of content authoring and packaging tools
• layout specifications (HTML5 and CSS3)
• a programming language (JavaScript)
• an underlying data model (DOM)

The difference is, these components are developed with a web experience in mind. This, to me, is the most significant benefit: the web platform is open, scalable, and well understood by countless developers.

Full disclosure: QNX releases first complete photos of new reference vehicle

"Any customer can have a car painted any color... so long as it is black."

We've come a long way since 1909, when Henry Ford penned this now-famous sentence. Not only can modern consumers pick the colors and features they want in a vehicle, but, in many cases, they can order them online. Getting the car you want, with the options you want, has never been easier.

Still, most forms of personalization are baked in. Once you order a car in, say, Barcelona Red (the color of my new Venza), it's hard to reverse the decision. But imagine the day when you can sit behind the wheel and watch your car's instrument cluster automatically reconfigure itself according to your personal preferences. And imagine if the cluster could do the same for everyone else who uses the car.

That's the kind of future QNX is working to make happen.

But you know what? I'm getting ahead of myself. I promised pictures of the new QNX reference vehicle, so let's look at them — especially since they offer tantalizing examples of what I was just talking about. :-)

The vehicle
Up to now, we've only released teaser images of the reference vehicle, with just enough detail to get people guessing as to what it might be. But enough with the mystery. Here's a full-on shot of the vehicle — a Jeep Wrangler Sahara — in all its off-road glory:


Yes, it's a Jeep

By the way, if you were one of the first 25 people in Canada or the US to guess it was a Jeep during our recent teaser campaign, congratulations! We'll identify the winners shortly.

The cluster
Once you get behind the wheel, the first thing you'll see is the digital instrument cluster. Let's zoom in so you can get a good look:



The cluster is implemented entirely in software and can reconfigure itself on the fly to display various types of information. Better yet, you can re-skin the cluster at the tap of a touchscreen button, like so:



As you can see, the cluster communicates with the head unit's navigation system to display turn-by-turn directions. Nice touch.

The head unit
Now look to your right, and you'll see the head unit. It supports a whack of functions (note my deft use of technical language), including one-touch pairing with Bluetooth smartphones, hybrid navigation, text-to-speech, natural speech recognition, streaming Internet radio, weather reporting, parking search, and too many other things to mention here.

In this photo, the head unit displays one of my favorite applications, the virtual mechanic. Intrigued? Check out my description of an early version of this app.



You know what else is cool? The unit's media player can post Facebook updates that list the song currently playing — but only when you tell it to, using voice commands. (Personal control over technology. I like that.) To view these updates later today and tomorrow while the Jeep is at Telematics Detroit, check out the QNX Facebook page.

Here's another photo of the head unit, showing its app tray:



The radio
What car would be complete without a radio? Mind you, in this case, "radio" includes support for streaming Internet radio from Pandora and TuneIn. And keeping in tune with the personalized listening experience these services offer you, the head unit's radio gives you a choice of skins:





In fact, almost every aspect of the head unit can be easily re-skinned. What's more, the underlying code remains the same: only the user interface, created in HTML5, changes from one skin to another. Which means automotive developers can create a single code base and re-use it across multiple vehicle lines. Doing more with less — what could be bad?

That's all I have for now, but before you go, check out the two press releases QNX issued this morning on the Jeep's personalization and Facebook features. Also, check out the QNX Flickr page for even more photos of the Jeep.
 

Making the smartphone connection: The state of automotive navigation in Japan

A guest post from Yoshiki Chubachi, the automotive business development manager for QNX Software Systems in Japan

The market for navigation systems in Japan grew rapidly until 2006, but since 2007 the yearly volume has reached the saturation point, at about 2.9M units. For instance, in 2008, consumers purchased 900k after-market systems, 1.1M dealer-installed systems, and 909k factory-installed systems. In 2010, those numbers had changed slightly: 1.01M after-market systems, 1.03M dealer-installed systems, and 858k factory-installed systems (source: Yano Research Institute).

That said, the market is starting to experience a shift from after-market to factory-installed devices. Automakers and their tier one suppliers are struggling to differentiate their products by implementing value-added features.

To get a feel for current navigation trends in Japan, let’s look at some notable after-market products that shipped in 2011. As you'll see, smartphones are exerting a major influence on this market, both in terms of system design and user features:

Pioneer AVIC-VH09CS — This high-end system combines augmented reality technology with a front-view camera, overlaying your route on a live video of the road. It also implements a collision warning system by measuring the distance of the car ahead. Other features include terrestrial digital TV (full HD and 1seg), DVD video, AM-FM, CD and SD music, iPod connectivity, and music ripping and encoding.

Clarion NX501 — The smartphone world seems to drive navigation trends, and the Clarion NX501 is no exception. It offers a touchscreen UI that supports swipes, flicks, and other finger gestures similar to those found in smartphones and tablets. Suzuki factory-installed systems also use the type of user interface.

Fujitsu-Ten AVN-F01i — This system comes with three bundled iPhone applications: Twitter Drive (combines tweets with location data), Where is My Car (uses augmented reality to show your parking location on the phone screen; great for finding your car in large parking lots); and News Reader (allows the system’s text-to-speech engine to read out news articles). The system connects to the phone through Bluetooth.

Panasonic CN-H500WD — The system also lets you use finger swipes to operate navigation and audio functions, including a scrolling map. It comes with a smartphone application that provides POI search, which is downloaded to the navigation system through Bluetooth.

Mitsubishi NR-MZ50 — This system provides an “OpenInfo” service based on Pioneer’s Smartloop system, which provides traffic data from a Pioneer server. VICS (Vehicle Information and Communication System) is a popular traffic data service in Japan that is similar to the RDS-TMC standard, but its coverage is limited to main highways. The smartphone receives traffic data, derived from anonymous traffic probe information, wherever the VICS service isn't supported. Information from the phone is transmitted to the navigation system through Bluetooth.

Connectivity between navigation systems and smartphones remains an issue in Japan. Conventional cell phones are equipped with the Bluetooth DUN profile, which enables data communication between the nav system and the phone, but unfortunately, some carriers still don’t support this profile. Until they do, lack of connectivity will remain a roadblock.

Nonetheless, using smartphones to deliver applications and the user experience has become a major trend in Japan’s navigation systems. Some automotive tier one suppliers, such as Pioneer, already provide navigation applications on the phone. The QNX CAR 2 application platform, with its mobile connectivity features and auto-centric HTML5 framework, offers an ideal foundation for enabling this approach.

Sound "bytes" from CTIA Wireless 2012

Several of my colleagues went to CTIA Wireless this week, and yes, they took the connected Porsche with them. No surprise there, of course: we’ve also taken the car to CES, MWC, BBW, and numerous other events. (Sorry, I’m really into acronyms today.) The Porsche, with its QNX-powered mobile connectivity and HD hands-free audio, seems to impress people no matter where it goes, and the reaction at CTIA was no different. In fact, the folks from Black Enterprise were so stoked, they awarded the car a CTIA Best in Show award. How cool is that?

Here’s a snap of the award, sitting on the car’s dash:



Meanwhile, Boonsri Dickinson of BYTE met up with Andy Gryc to ask him about QNX’s vision and technology for the connected car. Here's a video of their conversation — in the Porsche, of course:



Andy didn't spend all of his time in the passenger seat. Both he and Derek Kuhn also participated in connected car panels moderated by automotive journalist Doug Newcomb. The panels included "Apps in Automotive: The Future of In-Car Content" and "Can We All Just Get Along, for the Consumer's Sake?". From what I've heard, both sessions were taped, and I hope to post a link to the videos next week.
 

Everything you wanted to know about HTML5 in the car, Part III

Welcome to the third installment in my Q&A series on HTML5 in the car. In Part II, we looked at web servers, native plug-ins, instrument clusters, and display updates. This week, we turn our attention to tools, touch gestures, UI performance, and vehicle resources.

Are there any HTML5 HMI builder tools available?
Most of the well-known IDEs, including Eclipse, Dreamweaver, and Netbeans, support some flavor of HTML5 in their latest release. Adobe Edge, a new tool now available in preview, also lets you create animated HTML5 content. I suggest you check out the HTML5 Tools site, which publishes up-to-date tool reviews.

Often, automotive customers will ask system designers to make an infotainment system work "like an iPhone,” with the popular gesture controls. Does HTML5 support "inertial" menus and two-finger zoom?
Multi-touch is handled at the app level; here’s an example. Pinch zooming at the browser level is browser-dependent — the QNX browser handles it, but not every browser does. As for physics-based scrolling, HTML5 doesn’t support it “out of the box”; it needs to be added. Frameworks like Sencha Touch provide these types of controls.

Will the performance of HTML and JavaScript be adequate for critical user interface components or computations, such as safety-related notifications?
This has to be tested on a case-by-case basis. For the UI elements, yes, the performance should be adequate. Our testing indicates you can build HMIs that are surprisingly responsive. Also, our WebKit port lets you do things things like run JavaScript code in other tabs, threads, or processes to ensure those ocmponents aren’t being thread-blocked by something less critical.

I do get a little gun-shy recommending HTML5 for safety-critical components, because JavaScript isn't inherently real-time. If you wouldn't feel comfortable using Java for a critical coding task, you shouldn't use HTML5 either. If you want predictable, real-time performance for a lower-level computation that cannot tolerate any delay, the code should execute in a non virtual-machine environment. Most code doesn’t really fit that description, so most of the time JavaScript should work just fine.

How do you call vehicle resources — vehicle HMI, vehicle diagnostics information, etc. — on a HTML web app in the car? What's the process in plain words?
In plain words, it’s kinda hard. :-) But here’s my best take on this question: we solve this by creating a vehicle-bus driver that exports data through a publish/subscribe mechanism. The HTML5 layer talks to that piece through a JavaScript interface.
 

A quick tour of the QNX CAR 2 application platform

If you're looking for a quick, two-minute intro to the QNX CAR 2 application platform, you've come to the right place.

In this video, Kerry Johnson, automotive product manager at QNX, takes us on a tour of the platform, including its home screen, media player, application area, HTML5 support, phone app, and acoustic processing.

Ready? Then hit the Play button and let's get started:



In case you didn't know, the QNX CAR 2 platform forms the basis of the QNX concept car, a specially modified Porsche 911 that demonstrates what to expect in next-generation car infotainment systems. Earlier this year, the platform drove home with a 2012 Best of CES award, in the Car Tech category.
 

HTML5: Bustin' the myths

Did you know you can build HTML5 apps that don't use an Internet connection? Did you know you can run HTML5 apps without a web browser? And did you know HTML5 apps can show snappy performance even on automotive silicon? (As you can well imagine, in-car infotainment systems don't ship with quad-core server-class CPUs.)

If you answered no to any of these questions, you need to stop for a minute and check out this interview with QNX Software Systems' Kerry Johnson. Heck, even if you answered yes to all three questions, you'll probably still appreciate what Kerry has to say — and besides, you'll catch a glimpse of a complete in-car UI coded in HTML5. What could be bad?



While I have you, check out Andy Gryc's Q&A series on HTML5, if you haven't already. You'll find the first two installments here and here.
 

Everything you wanted to know about HTML5 in the car, Part II

Welcome to the second installment in my Q&A series on HTML5 in the car. Last week, we looked at CSS, cross-platform execution, and asynchronous design. This week, we turn our attention to web servers, native plug-ins, instrument clusters, and display updates.

If I don’t use a web server in my infotainment system, will I miss out on some features of HTML5?

A web server isn’t strictly necessary, but there are two very good reasons for including one. First, it lets you export a user interface to devices outside the car, thereby allowing mobile phones or tablets to run apps that are hosted on the vehicle head unit. Second, it lets you export internal car resources, as a URL, to HMI software running in the head unit. For instance, the web server could provide the HMI with access to static vehicle-configuration data (through an xml file) or to a back-up camera (through a video stream).

Will using native code plug-ins compromise my ability to leverage HTML5?

This is tricky, because a lot of things you want to do may require native code. So, yes, use native code, but do it judiciously. The more native code you use, the more it will limit the cross-platform capability of the HTML5 code that relies on it. The good news is that with HTML5 gaining so much functionality, plug-ins are needed far less than ever before.

A sample climate control app from the
QNX CAR 2 platform, created with HTML5.

Would you consider HTML5 as an option for cluster instruments: speedometers, tachometers, etc.?

At this point, I’d say no. HTML5 makes a lot of sense for in-vehicle infotainment, but it doesn’t provide the response needed for a vehicle cluster and it won't ensure safety-critical certification. Plus, the instrument cluster isn’t where you realize a lot of HTML5’s value: downloadable apps, connectivity to mobile devices, and so on. If the cluster and the infotainment system eventually merge into one big screen, then it’s more likely you could use HTML5 for both — but that’s still a few years out.

What’s a good way to get responsive display updates (10Hz update) into HTML5? Websockets?

If you need to deliver high-speed updates to your head unit, Websockets is one way to go. Make sure, however, that you don’t stall the rest of the JavaScript engine while your main thread is blocked on tasks. If you create another thread to monitor for changes, you can do it just as effectively (and probably with less work) with a JNEXT or NPAPI call into native code.
 

Everything you wanted to know about HTML5 in the car, Part I

My HTML5 webinar generated a lot of interesting dialog about what HTML5 means for in-vehicle systems. People asked questions about everything from security and performance to WebGL and cross-platform execution. Many of the same questions come up with when I speak with customers and analysts, which got me to thinking: Why not address them in this blog?

So without further ado, here is the first of my "FAQs" on HTML5 in the car. If you have a question and you don’t see it answered here, leave a comment and let me know! I’ll try my best to answer it in a future post.

How can you create multiple in-vehicle user interfaces using a single HTML5 code base?
The key to achieving this is the Cascading Style Sheets language, or CSS.

CSS controls the look and feel of web pages, but it can also be used to control the look and feel of a vehicle head unit. By changing a single CSS file, you can, for example, change all the fonts and background colors in a website (or head unit) from Arial and white to Verdana and black.

Mind you, CSS does much more than that. It also lets you specify how individual tags in HTML documents are displayed: layout, margins, sizes, colors, behavioral characteristics, events, and so on. Consider, for example, a phone app accessed through the vehicle head unit. If that app provides an HTML5-based user interface, each OEM could provide a default CSS that controls how the app looks on the head unit, adapting the app to meet in-vehicle usability standards and, of course, branding it.

A sample app from the QNX CAR 2 application
platform, created with HTML5

Let’s say your phone has an HTML5 navigation app that you want to run in your Audi today and your Chevy tomorrow. Although the phone serves up the app content identically in both cases, the Audi system can use a CSS to ensure that the app looks ‘Audi-like’, with that distinctive black and silver coloring, and the Chevy system can use a CSS that gives it the app the look-and-feel of OnStar. In effect, CSS can give the OEM more control over brought-in applications than other types of ‘screen replication’ technologies, like MirrorLink or iPod Out.

Keep in mind, though, that CSS can’t solve different OEM input philosophies, such as touch, hardkey, softkey and so on. You could use CSS to change the appearance for different inputs, but you would still need to have JavaScript hooking things up underneath.

You mentioned that cross-platform execution is a key benefit of HTML5. Do you have any recommendations on how to implement it?
Cross-platform execution is definitely something you want to keep in mind when designing software for vehicle head units. If you’re careful to ensure your app avoids features specific to the embedded environment, you can use mobile and embedded apps with the same HTML5 code base. It shouldn’t be difficult to make sure your app runs in both environments, but it’s better to plan for this going into design. That way, you can avoid using anything that prohibits cross-platform execution.

Could HTML5 replace the current HMI systems in head units that support multiple applications, and still be event driven and asynchronous in nature?
Definitely. JavaScript in HTML5 supports the concept of separate threads, called workers, that can handle events asynchronously. Although workers have some restrictions, such as the inability to modify the Document Object Model (DOM) or access globals, they should still be able to handle most asynchronous events. Maximum flexibility may require additional support from the HTML5 engine. To that end, QNX Software Systems has invested a lot of time in improving WebKit to allow code to run in separate engine web views, in different threads, in different processes, and even in completely independent HTML5 engine instances.

Stay tuned for Part II, where I plan to tackle questions on web browsers, web servers, and instrument clusters.
 

HTML5 Hackathon

Learn how to put together HTML5 apps at the HTML5 Hackathon. You'll get hands-on experience with WebWorks, which is the BlackBerry tool for building applications with HTML5.

That'll get you primed for building HTML5 apps for the QNX CAR 2 application platform!

HTML5 is a great option for the risk-adverse

The conservative nature of automakers makes them ideal candidates for the brand-spanking new HTML5. Say what?

While this seems paradoxical, it is an interesting take-away from the discussion between TCS' director of engineering Michael Camp and our very own Andy Gryc. If you've got three minutes to spare, watch the latest video in our HTML5 series for the whole story. (As usual, don't miss the ending. ;-)

This interview of Michael Camp is the fourth in a series from QNX on HTML5.

HTML5 and the software engineer

HTML5 appears to have a number of benefits for consumers and car manufacturers. But what is often good for the goose is not necessarily good for the developer. Talking to the guys in the trenches is critical to understanding the true viability of HTML5.

Andy Gryc and Sheridan Ethier, manager of the automotive development team at QNX, pair up for a technical discussion on HTML5. They explore whether this new technology can support rich user interfaces, how HTML5 apps can be blended with apps written in OpenGL, and if interprocess communication can be implemented between native and web-based applications.

So without further ado, here’s the latest in the educational series of HTML5 videos from QNX.



This interview of Sheridan Ethier is the third in a series from QNX on HTML5.

Is HTML5 a good gamble?

As the consumer and automotive worlds continue to collide, HTML5 looks like a good bet. And not a long shot either. In fact, the odds are all automakers will eventually use it. But since the standard won’t be mature for some time yet, should you take a chance on it now? 

To answer this, Andy Gryc talks to Matthew Staikos of RIM. Matthew is the manager of the browser and web platform group at RIM, and has over 10 years of software development experience with a strong focus on WebKit for mobile and embedded systems. Matthew co-founded Torch Mobile, which was acquired by RIM for their browser technology.

Andy’s conversation with Matthew is the subject of the following video, the second in an educational series designed to get an industry-wide perspective on HTML5. 

This interview of Matthew Staikos is the second in a series from QNX on HTML5.

What’s HTML5 got to do with automotive?

There’s been a lot of noise lately about HTML5. A September 2011 report by binvisions shows that search engines and social media web sites are leading the way toward adoption: Google, Facebook, YouTube, Wikipedia, Twitter, and plenty more have already transitioned to HTML5. Some are taking it even further: Facebook has an HTML5 Resource Center for developers and the Financial Times has a mobile HTML5 version of their website.

It won’t be long before HTML5 is ubiquitous. We think automakers should (and will) use it. 

To elucidate the technology and its relevance, we’ve created a series of educational videos on the topic. Here is the first in that series. Interviews with partners, customers, and industry gurus will soon follow. 

This simple overview is the first in a series from QNX on HTML5. (Personally I like the ending the best.)

Pimp your ride with augmented reality — Part II

Last week, I introduced you to some cool examples of augmented reality, or AR, and stated that AR can help drivers deal with the burgeoning amount of information in the car.

Now that we’ve covered the basics, let’s look at some use-cases for both drivers and passengers. Remember, though, that these examples are just a taste — the possibilities for integrating AR into the car are virtually endless.


AR for the driver
When it comes to drivers, AR will focus on providing information while reducing distraction. Already, some vehicles use AR to overlay the vehicle trajectory onto a backup camera display, allowing the driver to gauge where the car is headed. Some luxury cars go one step further and overlay lane markings or hazards in the vehicle display.

Expect even more functionality in the future. In the case of a backup camera, the display might take advantage of 3D technology, allowing you to see, for example, that a skateboard is closer than the post you are backing towards. And then there is GM's prototype heads-up system, which, in dark or foggy conditions, can project lane edges onto the windshield or highlight people crossing the road up ahead:



AR can be extremely powerful while keeping distraction to a minimum. Take destination search, for example. You could issue the verbal command, “Take me to a Starbucks on my route. I want to see their cool AR cups”. The nav system could then overlay a subtle route guidance over the road with a small Starbucks logo that gets bigger as you approach your destination. The logo could then hover over the building when you arrive.

You'll no longer have to wonder if your destination is on the right or left, or if your nav system is correct when it says, “You have arrived at your destination.” The answer will be right in front of you.

AR for the passenger
So what about the passenger? Well, you could easily apply AR to side windows and allow passengers to learn more about the world around them, a la Wikitude. Take, for example, this recent video from Toyota, which represents one of the best examples of how AR could make long road trips less tedious and more enjoyable:


 

QNX-based nav system helps Ford SUVs stay on course down under

Paul Leroux

This just in: SWSA, a leading electronics supplier to the Australian automotive industry, and NNG, the developer of the award-winning iGO navigation software, have created a QNX-based navigation system for Ford Australia. The new system has been deployed in Ford Territory SUVs since June of this year.

To reduce driver distraction, the system offers a simplified user interface and feature set. And, to provide accurate route guidance, the system uses data from an internal gyroscope and an external traffic message channel, as well as standard GPS signals. Taking the conditions of local roads into account, the software provides a variety of alerts and speed-camera warnings; it also offers route guidance in Australian English.

The navigation system is based on the iGO My way Engine, which runs in millions of navigation devices worldwide. To read NNG's press release, click here.


SWSA's new nav system for the Ford Territory is based on the Freescale
i.MX31L processor, QNX Neutrino RTOS, and iGO My way Engine.
 

Pimp your ride with augmented reality — Part I

The use of electronics is exploding in automotive. Just last week, Intel proclaimed that the connected car “is the third-fastest growing technological device, following smartphones and tablets.”

Ten years ago, you’d be hard-pressed to find a 32-bit processor in your car. Now, some cars have 4 or more 32 bitters: one in the radio, another in the telematics module, yet another in the center display, and still another in the rear-seat system.

Heck, in newer cars, you’ll even find one in the digital instrument cluster — the QNX-powered cluster in the Range Rover, for example. Expect to see a similar demand for more compute power in engine control units, drive-by-wire systems, and heads-up displays.


The Range Rover cluster displays virtual speedometers and gauges, as well as warnings, suspension settings, and other info, all on a dynamically configurable display.

What do most of these systems have in common? The need to process tons of information, from both inside and outside of the vehicle, and to present key elements of that data in a safe, contextually relevant, and easy-to-digest fashion.

The next generation of these systems will be built on the following principles:

• Fully integrated cockpits — Vehicle manufacturers see system consolidation as a way to cut costs and reduce complexity, as well as to share information between vehicle systems. For instance, your heads-up display could discreetly let you know who is calling you, without forcing you to take your eyes off of the road. And it could do this even if the smarts integrating your phone and your car reside in another cockpit component — the telematics module, say.
   
• Augmented reality — With all of the data being generated from phones, cloud content services and, perhaps more importantly, the vehicle itself, presenting the right information at the right time in a safe way will become a major challenge. This is where augmented reality comes in.

Augmented reality is a cool use of cameras, GPS, and data to create smart applications that overlay a virtual world on top of the real world. Here are some of my favorite examples:

AR Starbucks cups — Use your phone to make your coffee cup come alive:



AR Starwars — Blast the rebel alliance squirrels!



AR postage stamp — Add a new dimension (literally) to an everyday object:



And here are a couple more for good measure:

AR ray gun — Blast aliens around the house!

Wikitude AR web browser — Explore the world around you while overlaying social networks, images, video, reviews, statistics, etc.

Stay tuned for my next post, where I will explore how AR could enhance the driving experience for both drivers and passengers — Andrew.