Inspiration

I'm from Washington DC, & recently my city announced a partnership with Audi to give their vehicles a real-time heads-up display of upcoming traffic signals. I immediately wanted to create something like this for my car. I was delighted to find Virginia pioneering more open data practices that inspired me to head to Virginia Beach for a hackathon to use their incredible open data that's available to try to recreate this engineering feat in a weekend.

Repository is hosted at https://github.com/jauntywunderkind/traffic-light-headsup.

What it does

This is a mobile web application intended for use on phones or tablets, mounted in-car, in hands-free configuration. It tracks the user's location ongoingly, and display's a "heads-up" view of whatever traffic intersection the user is headed towards. This view includes:

  • A mirror visualization of the traffic light
  • A count down timer for how long the current phase is expected to last
  • A text description of the intersection of this traffic light

This application ongoingly polls the Smarter Roads' Signal Phase and Timing API, grabbing all real-time timing information that is available (presently, this is the Virginia Connected Corridor) and storing it into a geodatabase.

How We built it

Ahead of time, we scrape a bunch of static data into a PostgreSQL/PostGIS database:

  1. Map Data on intersections endpoint.This provides details on the physical layout of an intersection, giving us details about what signalling devices there are and what lanes of traffic they correspond to. This will be used to help us determine which signal is relevant to the user as they approach. It comes to us in the J2735 standard.
  2. Signal Data: Controller Configuration provides general information on the intersection: a human friendly description, it's latitude & longitude. We use this data to lookup the relevant intersection, & tell the user what light they are approaching.

With this base, we then start the application server, which serves two roles:

  1. Host a web application to run the users session. Running our web page, the user's browser sends our server geocordinates of where they are, & we stream them information about the approaching signal & the timing data relevant to them. The web page counts down the signal.
  2. A consumer which repeatedly reads the Signal Phase and Timing endpoint for updates, and injects all changes into a PostGIS spatial database.
  3. As signal phase & timing changes are read, locate any users who would be affected by this change, and inform them of the new signal component.

Accomplishments that Team is proud of

The team had a great time prototyping some early UI ideas to arrive at a design we are proud of as simple, low-distraction, highly visible.

We very quickly were able to get a basic mockup React-based web application brought up. We very rapidly added the location tracking feature & got that location funneling back to the server. Progress was super rapid.

We developed all the core technology we need to push updates between the mobile device & the server. We feel confident that the mechanisms to push intersection information, real time signal information to the phone, and for the phone to send it's location to the server, is a good, viable solution we could continue to use.

The team started out making a very valiant & strong engineering effort to read the J2735 standard data. We knew we needed a good tool kit to read the data, and we dived in to try to get an accurate model of the data structures in J2735. Even though we ultimately were not able to read the J2735 data, the team is incredibly proud of the useful J2735 models that it built, which serve all layers of this application. This work not only powers the application, but it got us deeply intimate right away with the data we knew we were targeting. As you'll hear in the next section, we failed to parse the encoded data, & but the presence of these models let us build the application solidly as though we did have this data working, and it enabled us to carry on forwards with confidence & enriched understanding of what would be possible.

Challenges Team ran into

The real-time data we are interested in, arriving from the Virginia Connected Corridor, all comes in the industry standard J2735 standard. It's wonderful that we have the potential to get the raw data. However our team found problem after problem trying to use this data.

First off, the J2735 specification is not available. We realized proceeding with this project would only be feasible with access to the spec, otherwise the data would remain largely a mystery, & so the team lead spend over $150 to purchase access to the specification on the day of the competition. We did eventually find an openly available ITT spec it was derived from, however that spec is ~8 years out of date. Access to this spec indeed proved critical, as outlined in our proud accomplishments above, however this was a big point of mystery & confusion beforehand. We like that the data is the raw data, but it's unfortunate that the ability to understand the data requires such a hih investment cost that many enthusiasts would not be willing to pay for.

Second, J2735 proved remarkably hard to work with. It defines what data structures are available via the faithful old standard Abstract Syntax Notation One (ASN.1)(, which is old but normal and there is a wide range of tooling available for ASN.1 data-dictionaries & reading & writing (decoding & encoding) tools. However, ASN.1 provides a number of different encoding formats. Here the team encountered radical difficulty. While encodings like DER (Distinguished Encoding Rules) and BER (Basic Encoding rules) are common and have ready support available, the UPER (Unaligned Packed Encoding Rules) encoding used throughout the Smarter Roads apis had very very few existing tools to work with it.

We use JavaScript throughout, and BER and DER are well supported in this environment. Additionally, common tools like dumpasn1 are frequently used to manipulate ASN.1. Libraries such as snacc provide a good fallback for writing C or C++ code to interact with ASN.1 if these options fail. None of these options worked with the UPER format.

The team located one and only one available tool that purported to support UPER, asn1tools, a swiss army knife converter that looked extremely promising & which would have served us well. However it was unable to read the J2735 data-dictionary. In our debugging we were not able to identify what was causing this incompatibility.

What Team learned

We learned an enormous amount about how & what transportation data looks like!

We learned a ton about the Virginia Connected Corridor, and the extend of infrastructure involved!

Our team had some really interesting discussions with others at the hackathon about DSRC vs Cloud systems. We're excited for the future, for 5G to happen, but also we really hope direct Vehicle to Vehicle and Infrastructure to Vehicle technology gets a chance. It was cool to know that the Smarter Roads endpoints are giving us data in the same kind of format as a 802.11 DSRC based ambient-computing world might have!

What's next for Heads-up

Getting our app talking to the J2735 endpoints remains a very high priority. Getting further into the source code of the promising asn1tools swiss-army knife to understand why it is failing to read the official J2735 schema is a likely path.

Once we have data better flowing through out system, we'd like to spend time better understanding the intersection data available to us. Being able to understand which lanes the user is approaching from, to confidently make the correct decision about which signal to show the user, is an important requirement for to bring this app to production, and a tricky problem. We also have work to do with better understanding which direction the user is heading, which is also important to making this decision.

With these two in to place, the team feels like it would be near to a good position to bring this application to production. Some UI cleanup - spit & polish - would certainly be in order.

Longer term, the team is considering adding technologies like speach assistant. For example, we believe we could serve a useful safety purpose if we detect the car moving quickly towards a red light, and vocally inform the user of the red ahead.

Built With

Share this project:

Updates