HUD output support

[n8willis]

It would be useful to be able to send messages to discrete heads-up-display units (HUDs), like the Garmin HUD and Garmin HUD+. The former, at least, uses straightforward Bluetooth messages:

http://hackaday.com/2014/03/30/controlling-the-garmin-hud-with-bluetooth/

But it has several forms of output: nav data, speed, and several form of alert, so tying it directly into one application would not work. There appear to be at least a few other similar HUD manufacturers out there, to.

[tripzero]

I had no idea garmin had such a product. I love this idea, however, I'm not sure how much information could be displayed from AMB. Speed is fine. That's easy. Routing and guidance information typically come from the navigation engine and AMB does not currently aggregate that data.

What I want to do is add bluetooth support in AMB's bluemonkey plugin so creating extensions for bluetooth devices like these in javascript is supported. The Valentine One also has a bluetooth interface. There's lots of fun stuff we can do.

[n8willis]

It's true that the Garmin one really only does nav -- I assume it, by default, gets its speed from GPS on the tethered navigation app -- but there are actually a few other such devices that show more telemetry-style info. Here's a blog post about one: http://www.techmoan.com/blog/2012/11/25/heads-up-heres-a-hud-that-plugs-into-your-cars-obd-socket.html

They seem to be cheapish items sold through eBay and the like. A few others turn up on Amazon; that one's not even BT, IIRC. Maybe it would be too complicated to support multiple, unrelated sinks that just happen to have a VFD attached...?

[tripzero]

Looks like the magic of the HUD is actually just in the reflective film. Creating a HUD from an OLED/LED display and a small computer should be actually pretty easy.

In that situation. you could run AMB directly on the HUD itself.

I feel a new personal project emerging...

[redheadedrod]

The film if you can get it is expensive. Unless there are new sources available now.
I found a place that had a $10,000 full screen HUD setup using a laser system. It was being developed for future use in Cadillacs.
In that model it was $1000 for the film to cover the windshield. The rest of that cost was for the laser and its interface to the computer. You still needed a method of checking for objects. It was an aumented reality setup. Was cool as hell and is likely to show up in the future.

The maker of that had the film available as a "demo" for $100 for 2 8x11 sheets. Where as the laser mentioned above did only spot marking on the windshield it would outline things like moving objects, people walking, the sides of the roads, the lanes. All sorts of stuff plus showed navigation information, speed etc. But for $10,000 it is a bit much.

The only purpose for the film is because windshields are tempered and are actually two pieces of glass with plastic in the middle. Any reflections are doubled.

There are APPS for phones to work as HUDS. And I will likely be working on something for my truck at some point. Using standard flat screens and ARM based devices to make my screens. I may revisit the laser projection stuff too since they were working on some new stuff for on window advertising.

A HUD would be very similar to a dash cluster. Just created as a mirror image.

Rodney

Date: Thu, 11 Dec 2014 12:39:45 -0800
From: notifications@github.com
To: automotive-message-broker@noreply.github.com
Subject: Re: [automotive-message-broker] HUD output support (#34)

Looks like the magic of the HUD is actually just in the reflective film. Creating a HUD from an OLED/LED display and a small computer should be actually pretty easy.

In that situation. you could run AMB directly on the HUD itself.

I feel a new personal project emerging...

—
Reply to this email directly or view it on GitHub.

                  =

[n8willis]

Well, backlit LCDs (including character displays and phones) are not nearly as bright as VFDs, which is what all of the HUD hardware products I've seen use. You might be able to see a phone display when you're driving at night, but the VFD HUD is designed to function visibly in daylight conditions, too.

In practical terms, I think we're talking about another output device class -- one that might also include character display LCDs, which I see a lot of hobbyist hackers modify as well. Some kind of serial output, where you'd have to configure what data it expects.

The Garmin HUDs are on deep discount at Amazon these days; I may pick one up and upload some sort of useful spec of the codes it uses.

[chaiken]

Here's some info about Honda's HUD:

http://tinyurl.com/kcxmf3u

Nothing there about light sources, alas. And a presentation by P.I. Victor Ng Thow-Hing, whom some of you will remember from Qt and MeeGo-IVI:

http://www.meetup.com/Autohack/events/184824722/

I thought Victor's slides were posted, but most of his presentation was in video form, anyway. I'm extremely impressed by this system, as its design clearly started with user needs, not with a technical solution in search of a problem. Consequently, the system is not a "science project," but looks pretty product-ready to me.

On another note, I wonder if it would be possible to do a group buy of the windshield film, say from AliBaba?

Best wishes,
Alison

[n8willis]

Thinking a little more about this, for the nav HUDs it seems like we'd definitely need a source plugin that hooks into the navigation engine in order to grab the notifications needed (e.g., something simple like JSON saying 'next turn 500m left' or whatever). AFAICT, Navit doesn't have a simple API that's usable for that, so that'd have to come, too.

Then I guess each HUD unit would (potentially) require its own sink plugin....

The speedometer-only HUDs (for sale cheap on eBay etc) could probably listen to the GPS source.

Unless I'm overlooking something; perhaps there's a way to pull navigation updates with the websocket plugin. Or a w3c navigation API to go through.... It seems like it'd be rather nav-engine specific. Still would be cool, though, and potentially useful.

[tripzero]

navit may have been patched to expose the GENIVI navigation API which
probably works over dbus. Using bluemonkey's DBus API, you could probably
expose source functionality for this with only a few lines of javascript
code.

http://projects.genivi.org/ivi-navigation/documentation
API:
http://git.projects.genivi.org/?p=lbs/navigation.git;a=blob;f=api/navigation-core/genivi-navigationcore-guidance.xml;h=e03fc45f10b39a204aa8c78a13d2405e3be8397a;hb=HEAD

I don't have much time to do the legwork at the moment, but if navit works
and exposes this API, getting AMB to use that info will be really easy.
I'd be happy to guide anyone willing to try it out.

-Kevron

On Thu, Apr 23, 2015 at 10:35 AM, n8willis notifications@github.com wrote:

Thinking a little more about this, for the nav HUDs it seems like we'd
definitely need a source plugin that hooks into the navigation engine in
order to grab the notifications needed (e.g., something simple like JSON
saying 'next turn 500m left' or whatever). AFAICT, Navit doesn't have a
simple API that's usable for that, so that'd have to come, too.

Then I guess each HUD unit would (potentially) require its own sink
plugin....

The speedometer-only HUDs (for sale cheap on eBay etc) could probably
listen to the GPS source.

Unless I'm overlooking something; perhaps there's a way to pull navigation
updates with the websocket plugin. Or a w3c navigation API to go
through.... It seems like it'd be rather nav-engine specific. Still would
be cool, though, and potentially useful.

—
Reply to this email directly or view it on GitHub
#34 (comment)
.

[n8willis]

Can you explain what you mean?