We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Connected Cars with PouchDB

00:00

Formal Metadata

Title
Connected Cars with PouchDB
Title of Series
Number of Parts
188
Author
License
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Producer
Production Year2014
Production PlacePortland, Oregon, United States of America

Content Metadata

Subject Area
Genre
Abstract
Connected cars are everywhere and writing apps for connected cars is an emerging space. OpenXC is an open JSON data API for Ford cars that enables developers to write custom apps for telemetry data in real time, this includes geographic location.Bandwidth and connectivity in a car is limited however and as such an app needs to be written to be offline first. This talk discusses the difficulties of connected cars and how to overcome this big data problem with PouchDB, CouchDB, Leaflet and Google Chrome Applications.
Keywords
25
74
Thumbnail
29:15
Device driverElectronic visual displaySoftware developerAsynchronous Transfer ModeInternetworkingData storage device1 (number)Mobile appMultiplication signConnectivity (graph theory)Process (computing)Tablet computerValidity (statistics)Antivirus softwarePoint cloudResultantLocal ringMashup <Internet>Computer virusModule (mathematics)Computer clusterComputer hardwareValue-added networkWebsiteSoftware protection dongleBuildingOpen sourceComputing platformCycle (graph theory)Type theoryInterface (computing)Graphical user interfaceTelematikDatabaseMathematicsDemo (music)FamilyModal logicMoment <Mathematik>Position operatorRule of inferenceTrailGraph (mathematics)Sound effectMaxima and minimaForm (programming)Endliche ModelltheorieVisualization (computer graphics)Musical ensembleTemplate (C++)Social classCAN busBit rateReading (process)MappingSampling (statistics)TheoryFlow separationWordMobile WebVolumenvisualisierungCartesian coordinate systemReal-time operating systemMetadataRight angleControl flowPhysical systemWorkstation <Musikinstrument>SpacetimeTournament (medieval)Open setCausalityExecution unitSource codeMatching (graph theory)
Server (computing)Web pageQuery languageMereologySpeech synthesisExtension (kinesiology)AreaCartesian coordinate systemPatch (Unix)Android (robot)WindowError messageGraph (mathematics)Key (cryptography)Multiplication signRadiusEvent horizonCASE <Informatik>Line (geometry)TouchscreenComputer fileTrigonometric functionsVideo gameInformation securityMarginal distributionGeometryÜberlastkontrolleRow (database)Data storage deviceMappingFreezingAdditionFrame problemType theoryPattern languageWeb browserResultantInformationService (economics)DatabaseAsynchronous Transfer ModeShape (magazine)Connectivity (graph theory)Link (knot theory)Counting1 (number)Execution unitState of matterArchaeological field surveyDistortion (mathematics)Touch typingLogic gateControl flowCondition numberEquivalence relationVolume (thermodynamics)Object (grammar)Vertex (graph theory)Process (computing)Data managementMathematicsComputer virusWeb 2.0Directed graphPrisoner's dilemmaRight angleSource codeDefault (computer science)Particle systemReduction of orderCharge carrierCrash (computing)Dependent and independent variablesReading (process)Presentation of a groupComputer simulationSet (mathematics)Thread (computing)Matching (graph theory)PlanningSoftware testingTracing (software)Structural loadInverse elementPoint cloudClient (computing)Film editingPeer-to-peerSoftwareCommutatorCommunications protocolSynchronizationGraphical user interfaceTablet computerDemo (music)Level (video gaming)Open sourceBitInterface (computing)Near-ringCross-platformMobile appOpen setWeb application
Connectivity (graph theory)Front and back endsVolume (thermodynamics)DatabaseTablet computerInterface (computing)Term (mathematics)Graph (mathematics)Line (geometry)Event horizonWeightCASE <Informatik>Data storage deviceCausalitySimilarity (geometry)Information securityImage resolutionObject (grammar)DigitizingComputer animationLecture/Conference
Transcript: English(auto-generated)
OK, well, let's get started. It's now 10. So today, we're talking about connected cars with PouchDB. And it's so great to see some of your PouchDB former committers and committers here in the audience is great, as well as PouchDB, as well as Cashbase, as well as Cloudant. So let's get started. So what we're going to talk about today,
we're obviously going to talk about connected cars. It's in the title. But we're in particular going to talk about Ford OpenXC. I'm going to go into some details of what that actually is. And also, where's the Chrome app? Because the Chrome app was kind of essential for doing our demo that we did for Ford. None of this was possible without PouchDB, which is an offline JSON database.
And I'm going to go into some detail about that. I'm also going to talk about Cloudant, how it's advanced geospatial API was very useful in this example. And I'm going to go into some detail about how we brought it all together to create a connected car app. And if anyone can't hear me or have problems with my accent, please ask me to repeat myself. I don't mind.
And finally, we're going to finish this all up with a demo. I actually have a live demo of the Chrome app running. And if you stay to the end, I'll tell you about prizes that we're giving away. I wish. So connected cars, I mean, the thing is, who has a connected car? Well, it's Audi, BMW, Ford, and Lexus.
That's the obvious ones. There's also April, Renault, and Volvo, if you're more European. And there's also Tesla, Daimler, and many, many others. This is a hugely emerging market right now. What is a connected car? So vendors are no longer reliant on an in-board display.
Mobile phones are updating more frequently than cars update. So changing your display in the car, you just can't do it if you take the screws off. You have to go and undo the wires. Whereas connecting your phone, you can just do it. So you can have your latest Android, your latest iPhone, that can be reading data from your car. Connected to a mobile phone or a tablet,
it's not always a phone. If you're in a routing company, for example, like UPS or FedEx, you're probably gonna have a tablet rather than the phone. So you wanna really connect your tablet to the car or to the van. Here's the key thing. Here's the key thing that's driving it because these vehicle vendors are seeing opportunities to build engagement apps that stem beyond the car.
They want you to be able to read the telematic data from your car, take it back home, and assess your driving. How can I change my driving to go increase my fuel economy, for example? How can I change my drive to go increase my tire wear? Those type of things that are of interest or if you're a particularly bad driver, of course, the insurance companies are very interested in that data.
Connected to a car will read the telematic data and I'm gonna go into some detail of what data's available. But you can think of things like, most cars nowadays have GPS enabled on them. It can also read your foot position on the throttle pedal. It can read when you press the brakes, when your lights are on, when your wipers are on, when the doors open, you know, who's sitting where. It can read pretty much everything, as long as it's read only.
It can also broadcast alerts. So emergency alerts is the obvious ones and I'll give you a few more examples of some others. One of the key things for a developer is that there are very strict rules on distracting a driver. Pretty much, if you're gonna write an app for a connected car, you have to have it in locked mode.
You don't actually have a visual display. So the only things that are available to you are either very simple button presses that you could unlock and hit, or more than likely, it's just vocal commands only. So either you're directing the phone with your own voice or you're receiving vocal alerts back.
So example apps. This is one of the first ones that came out from a hackathon that Ford did a couple years ago. As your speed increases, let's bring up the tempo of the music, which to me is a very crazy idea because as I'm a driver, I would drive even faster and faster and faster. And also, it's gonna send you traffic alerts, so I'm gonna go into some detail in a minute
about Ford's challenge, which was a traffic tamer in London. Didn't want to alert people when there's gonna be problems up ahead in real time. Not waiting for some helicopter. Don't know how many people know about London, but they fly helicopters around. They say they're looking for travel spots. You miss so much. By the end of the crowdsourced that day, they're gonna get more accurate results.
Fleet people want to monitor wear on a vehicle. You know, if you're pressing your brake a lot, you're always gonna be wearing out your brake pads. Taking the wear off, checking your brake pads is a real pain. Being able to monitor that by some diagnostic on a cloud is very, very useful. One of the other apps that was actually demoed again
about 18 months ago was when they were doing a mashup of weather data and this car data. So when there was a local rain ahead, it automatically turned the lights on in the car. Again, if your airbag deploys, you might be unconscious, and it's just the way that they want to alert 911
or alert your family members to come and help you. And tracking of leased cars. You can get your price down if you drive carefully, basically. This is something that leasing companies and insurance companies are pushing. You know, if you don't drive successfully, everyone drives a higher car like you stole it. You know, it's not your car, so you're gonna drive it really, really quick
and don't really care if you mash it. Well, if you drive it carefully and they've got your history of driving carefully, your price will probably go down. Probably wouldn't change my habits. And they also want to know about road damage. So say you're a local county and you've got to go and resurface your roads. Well, you better track how many cars went over
and what speed, and you better do some aggregate there to go and decide whether the road size is deteriorating. You wouldn't have to send someone out to check it. Connect to car problems. Limited display, I mean, we touched on that. There isn't very much you can do if you're only allowed a couple of button display or you have to be locked or it's vocal commands only. So that's actually gonna cause the problems
for app developers. They're not using like Google Play or using App Store. They're actually deploying their own app stores. So Ford's gonna have their own app store. Renault will have their own app store. Problem is how do you get on it? Because the actual validation process for your app is quite long and intensive.
For the traffic team, they went through that process and we had to change ours a couple of times. Virus protection. People are already cashing in on this right now. I don't actually understand the rest because you can primarily read only. It's not too bad, but people like some virus companies are advertising solutions now for getting their cars
and making quite a lot of cash. The other problem is because of the delay on getting on the vendor app store, the actual cycle of updating your displays when you get feedback from the users is gonna be quite slow. I like Android because it's very critical to go and update your app on the app store.
Apple's not too bad. App stores for cars because the necessary long validation process is gonna take longer cycles of development. And the joke within Cloudant is we don't really know why it's called a connected car because you're disconnected most of the time. So it's a disconnected car.
You don't really have a internet connection or local connection on most of your journey. So what is Ford OpenSC? And I grabbed this from their website and you can see it's totally open source and I tried to enlarge it here. You can go and check it out afterwards. It is an open source hardware and software platform that lets you extend your vehicle
with custom apps and pluggable modules. The key thing there is the thing in the middle, which is the OBD2 port. And then they have a little dongle there you can connect. And then from that dongle, we can either directly connect with USB or we can connect with Bluetooth. And the fun thing is that these have been available in Ford cars for the last 10 years, if not longer.
I mean, you can get a Mustang from around about 2000, it has it in there. But they've only been advertising this interface now for the last 18 months, two years. So they anticipated this over 10 years ago, which is quite incredible. So I encourage you to give this a go.
These OBD2 ports, you build them yourself, they cost less than 50 bucks. Yeah, they're great fun. So one of the things I kind of jumped at when I saw OpenHC is that the data coming off your little device is JSON. I don't have to do any manipulation, it's JSON out of the box, not some crafty XML.
It's just JSON. And this is just an example of some of the things that come off the device. Vehicle speed, for example, is elevated pedal, your GPS stem and lat and long, your fuel level, your torque. But it is also things like wipers, lights, you know, who's sitting where, that type of thing. Depends how many sensors the car has.
You pretty much guarantee vehicle speed, accelerated pedal, brake, and GPS, either through your phone or through your GPS on the car. There's much, much more available. There are SDKs from Ford and Android and Python, but that wasn't really good enough for what we wanted to do because we wanted to deploy on an iPhone as well.
So we want to be on iPhone, Android, Windows tablets, pretty much everything. So we write an SDK in JavaScript, which is an open source. You can download it from Cloudant's GitHub page. We call it openxc-js. You can just put it down. It's pretty complete. You know, just get an idea of what's get to the page.
So what about Cray Maps? Why do we need Cray Maps? Because we want it to be cross platform. We want it to run on Windows, Mac, Android, iPhone, pretty much anything. And also we wanted a deployment that was really easy for us at the time, and that was through the Cray Map store. And another key thing is that a Cray Map will run in the background, so it can be offline and online as well.
It already has Bluetooth and USB connectivity for its native APIs. It has an excellent text-to-speech engine, which means that we could eliminate the need for a UI. We could actually go and alert people when something is happening. We could lock the screen, and it would still be running. And then the key thing is it's an HTML file application that's based on the native APIs, and through something like Cordova,
you can go and deploy this to a mobile phone. So PouchDB, it wouldn't have been possible without PouchDB for our offline storage. And I grabbed this directly from the PouchDB webpage. I didn't wanna do it in injustice. PouchDB is an open-source JavaScript database inspired by Apache Couch that's designed to run well within the browser.
It's key thing is it works offline as well as online. And then you can sync it with CouchDB and compatible APIs. So you can sync it with Cloudant Couchbase, or anything that's out there that's gonna work, where it would replicate to our interface.
So Cloudant is only very brief because I wanted to show you that we use PouchDB and then we sync it to Cloudant. Cloudant is a distributed database as a service. So it has resale uptime, we're always available. So you think of a high volume of cars where you need to uptime to be able to sync that data. You can't have a server that's down. We offer advanced geo capabilities, and that's how we do radius search
for where the traffic damage is, and we'll come to that in a minute. And then in this particular example, we sync from PouchDB up to Cloudant, but you could just as easily sync from the PouchDB to CouchDB. It depends on your availability requirements. So bringing all the carries is the bit I wanted to get to quite quickly.
We entered the Ford Traffic Tamer Challenge back in March. There were about 50 or 60 people who entered. And the aim was to reduce traffic congestion in London, which is in the United Kingdom. We thought it'd be a great way to go and talk to people like Ford and BMW, Audi, et cetera. So we wrote these in a couple of days, and it really has opened some doors, so I would keep looking at the Ford Traffic Challenges.
They come out every couple of months. You get to meet some very good people if you enter here. And the reason we were able to write this in a couple of days was, well, because of Cloudant, because of Pouch being so simple, and because of Craymap being incredibly easy to deploy
to the components. We have the Craymap, which is one of the two. We have a Web Worker, so a Web Worker is like a background thread for a Web App. And within that Web Worker, we're running PouchDB, so the UI, in this case, the vocal alerts are always active. And we also had another Web Worker because the people judging this challenge, weren't going to drive our app around in a Ford car.
They wanted to run it on their desktop or on their phone. So I wrote a simulator for OpenXC JS, so it was reading a trace file and playing those events back as if they were happening, and we just put that in the Web Worker. So that's our OpenXC feed simulator. And again, that's open source, so you can download that from OpenXC-JS on Cloudant's GitHub page.
And then using the Cray Native extensions, we have a text-to-speech engine. And of course, we use PouchDB, so the features. The application is offline first. Everything from the car is being written offline, so it's being written to Pouch when not assuming connectivity.
That means you have a very low latency access to store your data. You're not getting up to do a server hop, you're storing it locally on your phone. And these trace files, the inverse loads and loads of events a second up to a cut of 100. It's only a couple of gigabytes when it's inside Pouch or inside CouchDB or wherever you wanna run. I mean, for a whole day.
So traffic alerts can be fed from a third party. Or of course, because we're monitoring people when they press their brakes or their speed, when they actually stop, we can crowdsource that data with MapReduce on the server side and say, there's a traffic congestion here, it's a hotspot, go and alert the user.
It works with low bandwidth because we're not assuming connectivity. Peer-to-peer, this is the key thing, this is kind of cool. So road networks are getting to introduce Ad-hoc Wi-Fi. So as you're going along the road, you can have occasional connectivity and through that we can go peer-to-peer over cars, we can use them as a handshake service.
WebRTC is gonna be something that's gonna come to the fore, I think, for connected cars. WebRTC is a protocol for peer-to-peer through the web browser, noted by Google a few years ago. Everyone's offline. And of course, there's emergency responses, always gonna be a big play there.
When there's a car crash, you wanna go and get 911 there as fast as you can. So here's the actual workflow. So even with the simulator, we're running 10 to hundreds of events every second, and we're writing those to PouchDB. But we don't wanna be able to sync that with the server because that's too much data, too much to be writing up all the time. We're saying, you're primarily offline, you might be on a really expensive phone connection,
you don't wanna be syncing your data. So only an actual event is gonna be synced to the server. So if you stop your car, for example, you're a zero, and we know you're not parked, then that means there's some rejection that we want to alert other users in the facility. Every 30 seconds or so, the client does a very simple query for traffic alerts in that area,
does a radius search against cloud and geo, and then any events come back. Then when the user disconnects, goes home, when they go in the garage or wherever they're going, when they're on WiFi or 4G, that whole data is synced. That means that the cloud will have all your data,
how you drive your car. Of course, there's some permission issues and security issues there you have to be concerned about, and the data can be analyzed after the commute. So we can say things like, if you started your commute 10 minutes later, you'd actually save half an hour that day, so we can assess your driving pattern. So I thought I'd try and show you what the data looks like inside PouchDB.
So, because we're using Chrome, we get this excellent debugging tool, and I'm showing the resource here within the web browser, and you can see that here's PouchDB, and on the right-hand side, you can see the geo JSON objects. And in this case, we're showing a celebrated pedal for your engine speed, for your consumed, you know, and there's hundreds and hundreds of these in there.
Then if you press sync, you'll get it stored within cloud, and so cloud is on the cloud. So here's it showing an event that's been synced to trigger an alert. In this case, we're triggering on vehicle speed, and the value is pretty low. You're only getting one to two miles per hour, so we're assuming there's some traffic congestion coming up.
So now I'm gonna go into a demo. So again, this could run on your tablet or your phone, but I'm running it here inside Chrome as a Chrome app, and this is actually on the Chrome app store, and if you go to openHC-JS, you can find all the links and the information, but I'm gonna show it in debug mode. Let's make sure the volume's up.
Hope we launch the app. So this is showing a map of London. So this is in debug mode right now, so I want to show you what's going on, but of course, normally your screen is locked because you're driving. I'm gonna choose a trace file, which is running inside a web worker. So london.json there.
And in a minute, it will zoom across. Traffic slowing at even house. So it's done a query against Cloudant there and found that, okay, there is actually a traffic alert near you. Come back, turn that into a text-to-speech engine and reach out to you on your phone. At the same time, all your data is being synced into PouchDB.
So I'm on WiFi right now, but I can sync the whole lot up to Cloudant by pressing the sync button just there. And that's just synced to all the Cloudant. Okay, and that concludes my presentation. Does anyone have any questions?
So you mentioned this was for the Ford OpenXC device that was connecting between a tablet and the ODBC2 connection. That's correct. Did you also say you could make a similar device if your vehicle did not support that or have that piece of equipment? Yeah, that's correct.
There's also SDKs for BMW, Audi, Daimler, Tesla. So in order to save this data from the interface, is the interface sending the JSON to the tablet or is it being stored on the interface or on that device and then you pull it off? The port has no storage. It's just reading it in real time. So it's your phone or your tablet that's doing the storage
and in that case, we're doing it inside PouchDB. Okay, cool. What kind of data volumes are kind of the general guidelines or your target
in terms of what the car companies are looking for and then what you can reasonably move around? Well, a car can store terabytes because we distribute it across multiple nodes and we're having 10 to 100 events every second and they're normally one line adjacent which is what like 30 characters.
So it's pretty high volume which is why you need a high available distributed database on the backend. But your actual one car is not generating that much data. It's the volume of cars that's generating the data. Any other questions?
Well, thank you very much. Oh, sorry. Okay, thanks very much for your time. Thank you.